[Bug c++/19773] warning for misplaced semicolon is C-only
-- What|Removed |Added Summary|warning for misplace|warning for misplaced |semicolon is C-only |semicolon is C-only http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19773
[Bug c++/19773] New: warning for misplace semicolon is C-only
The following program is valid C and valid C++. In either language, it
probably doesn't do what the
programmer thought it did.
bool f();
void g();
void h() {
if (f())
g();
}
Compiling this as C, we can get a warning about this:
[tmp]$ gcc -c -Wall -W foo.c
foo.c: In function 'h':
foo.c:5: warning: empty body in an if-statement
Compiling as C++, we get no such warning. Why? This mistake is just as bad in
C++ as in C.
--
Summary: warning for misplace semicolon is C-only
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple 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=19773
[Bug c++/19628] [3.4/4.0 Regression] g++ no longer accepts __builtin_constant_p in constant-expressions
--- Additional Comments From austern at apple dot com 2005-01-31 02:38 --- Subject: Re: [3.4/4.0 Regression] g++ no longer accepts __builtin_constant_p in constant-expressions > it checks for built-ins that can appear in consant-expressions, but > the name > might seem to refer exclusively to __builtin_constant_p. A name like > "builtin_valid_in_constant_expr_p" would seem better. I agree, that's a better name. I'll change it. > (Matt, I think you should also check what happens when > __builtin_constant_p is > used as a template argument with dependent arguments, like: > template > void f(int &[__builtin_constant_p (I) + 2]); Actually, it ICEs. That would be a regression. I think I'd better fix it before checking this in. --Matt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19628
[Bug c++/19628] [3.4/4.0 Regression] g++ no longer accepts __builtin_constant_p in constant-expressions
--- Additional Comments From austern at apple dot com 2005-01-28 20:17 --- This was undoubtedly caused by Mark's large checkin on 2003-01-29, which included changes to constant-expression handling. I do not believe the __builtin_constant_p change was deliberate. The intent behind this patch, as far as I can tell, was to reject constructs that the C++ standard explicitly says are not constant-expressions, such as "(1, 2)". It looks to me like rejecting GNU extensions like __builtin_constant_p in constant- expressions was just a side effect. As far as I can tell, rejecting __builtin_constant_p is a change that (a) was not deliberate; (b) is undocumented; (c) introduced a C/C++ incompatbility; and (d) causes previously working code to break. I think that justifies calling it a bug. -- What|Removed |Added Keywords|rejects-valid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19628
[Bug c++/19628] New: g++ no longer accepts __builtin_constant_p in constant-expressions
The following test case is accepted by 3.3 (both C and C++) and by 4.0 C, but
not by 4.0 C++.
#define FOO(x) (__builtin_constant_p(x) ? 1 : 2)
int foo(int n) {
switch(n) {
case FOO(3):
return 1;
default:
return 2;
}
}
Was this change intentional? Even if it was, the C/C++ incompatibility is
unfortunate. This sort of
construct is likely to appear in headers used by both languages. (And we can't
very well point to
language standards in deciding whether __builtin_constant_p should be
considered a constant-
expression, since it's a GNU extension.)
--
Summary: g++ no longer accepts __builtin_constant_p in constant-
expressions
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.7.0
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19628
[Bug c++/11036] typedef-name used in an elaborated-type-specifier is incorrectly accepted
--- Additional Comments From austern at apple dot com 2005-01-24 18:06 --- I've raised this issue on the C++ standardization committee's core language reflector. I now find it a little less clear than I did before. This is closely related to open issue 407. See http://www.open- std.org/jtc1/sc22/wg21/docs/cwg_active.html#407 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11036
[Bug c++/19538] Missing diagnostic for typedef name in elaborated type specifier
--- Additional Comments From austern at apple dot com 2005-01-24 18:06 --- I've raised this issue on the C++ standardization committee's core language reflector. I now find it a little less clear than I did before. This is closely related to open issue 407. See http://www.open- std.org/jtc1/sc22/wg21/docs/cwg_active.html#407 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19538
[Bug c++/19538] New: Missing diagnostic for typedef name in elaborated type specifier
Consider the following code sample:
struct A { };
typedef struct A A;
struct A a; // [1]
struct wrapper {
struct B { };
typedef struct B B;
struct B b; // [2]
};
Mainline gives an error for line [2], but not for line [1]. My reading of the
standard is that there
shouldn't be any difference. In both cases we're using an elaborated type
specifier with a name that
resolves to a typedef-name. A program that does that is ill formed, so the
compiler is required to
admit a diagnostic. We're doing that for line [2], but we're failing to do it
for line [1].
Relevant passages in the standard: 3.4.4/2, 7.1.3/4, 7.1.5.3/2.
--
Summary: Missing diagnostic for typedef name in elaborated type
specifier
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.7.0
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19538
[Bug c/19455] New: typeof no longer works for bitfields
The following program
struct X { unsigned n : 1; };
int main() { struct X x; typeof(x.n) tmp = 0; return tmp; }
compiles without error in 3.x, both as C and as C++. In 4.0 it still compiles
without error as C++, but
no longer as C. Nothing in the documentation for typeof
(http://gcc.gnu.org/onlinedocs/gcc/
Typeof.html#Typeof) suggests that typeof behaves differently in C and in C++,
or that there is a
restriction on its use with bitfields.
This may be indirectly related to standard conformance issues, but the relation
can't be very direct;
typeof is a GNU extension, so any documented and consistent behavior is
correct.
We should either change the documenation to say that typeof no longer works
with bitfields in C, or
make it work again.
--
Summary: typeof no longer works for bitfields
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple 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=19455
[Bug c++/12333] [DR 272] Explicit call to MyClass::~MyClass() not allowed
--- Additional Comments From austern at apple dot com 2005-01-05 05:24 --- I was wrong in thinking this was only a diagnostic bug. DR272 only affects a nonnormative note. I've checked with Mike Miller, and he pointed me to the appropriate normative text that implies that X::~X() within a member function designates the destructor. This is a genuine rejects-valid bug, not just a bad diagnostic. It is a rejects-valid bug regardless of the status of DR272. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12333
[Bug c++/19243] Misleading error message for ill-formed explicit destructor invocation
--- Additional Comments From austern at apple dot com 2005-01-05 05:21 --- Nope, I was wrong. DR272 only affects a nonnormative note. I've checked with Mike Miller, and he pointed me to the appropriate normative text that implies that X::~X() within a member function applies to the destructor. This is a rejects-valid bug, not just a bad diagnostic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19243
[Bug c++/19258] New: Incorrect access check for default argument
The following code
class X {
template friend int ff(T*, int y=anX.x) { return y; }
int f() { return ff(&anX); }
static X anX;
int x;
};
X dummy;
gives an error message with mainline:
foo.cc:6: error: 'int X::x' is private
foo.cc:3: error: within this context
That error message doesn't make sense. The only relevant contexts are that of
X::f (in which x may be
accessed, since X has access to its own members) and that of ff (which has
access because it is a friend
of X.) The analogous non-template case compiles correctlly.
This is a regression from 3.3.
--
Summary: Incorrect access check for default argument
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.7.0
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19258
[Bug c++/6628] cannot typedef const functions
--- Additional Comments From austern at apple dot com 2005-01-03 21:46 --- 9.3/9 isn't the most relevant part of the standard. Yes, that gives an example showing that this syntax is legal, but examples are non-normative. They're mostly useful for establishing the intent of the committee. The relevant normative text is in 8.3.5/4, which makes it quite clear that cv-qualifiers are allowed in typedefs for function types and which explains what they mean. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6628
[Bug c++/19245] New: gcc reject cv-qualifiers in function type typedef
For the following code
typedef void f(int) const;
gcc gives the following error message:
foo.cc:1: error: invalid type qualifier for non-member function type
foo.cc:1: error: 'const' and 'volatile' function specifiers on 'f' invalid in
type declaration
That error message is incorrect. As 8.3.5/4 makes it clear, cv-qualifiers are
valid in type declarations.
9.3/9 uses a typedef very much like this one in an example.
--
Summary: gcc reject cv-qualifiers in function type typedef
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.7.0
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19245
[Bug c++/19243] Misleading error message for ill-formed explicit destructor invocation
--- Additional Comments From austern at apple dot com 2005-01-03 20:55 --- Subject: Re: Misleading error message for ill-formed explicit destructor invocation On Jan 3, 2005, at 12:49 PM, pinskia at gcc dot gnu dot org wrote: > > --- Additional Comments From pinskia at gcc dot gnu dot org > 2005-01-03 20:49 --- > Hmm, I think this is valid code and should not be rejected, see DR 272 > and PR 12333 (which I think this > is a dup of). DR 272 is in "WP" status, meaning it's part of the working paper for C++0x. It's not part of the International Standard ISO/IEC 14882:2003. I couldn't find anything in the standard saying that it was acceptable to write an explicit destructor call using a qualified-id. Did I miss something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19243
[Bug c++/19244] New: Typedef of anonymous class incorrectly handled in member function definition
gcc 4.0 incorrectly rejects the following valid code:
typedef struct { void f(); } f;
void f::f() { }
It treats f::f as referring to a constructor, and then gets confused because
this isn't the right syntax for
a constructor definition. However (12.1/3), "a typedef-name that names a class
shall not be used as
the identifier in the declarator for a constructor declaration."
Note that this only happens for an anonymous class. If I instead write
typedef struct e { void f(); } f;
then this compiles without error.
This is a regression. 3.3 handles this correctly.
--
Summary: Typedef of anonymous class incorrectly handled in member
function definition
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.7.0
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19244
[Bug c++/19243] New: Misleading error message for ill-formed explicit destructor invocation
gcc 4.0 gives an error message for the following file:
struct X {
void destroy_me() { X::~X(); }
};
This code is incorrect, so an error message is appropriate. However, the error
message isn't likely to be
useful.
The error message we get is:
foo.cc: In member function 'void X::destroy_me()':
foo.cc:2: error: '~X' is not a member of 'X'
But that's not the real problem. Obviously ~X() is a member of X. The real
problem is that this is the
wrong syntax for an explicit destructor invocation: the user should have
written this->X::~X(), not X::
~X() by itself.
(See the formal grammar for postfix expressions in 5.2/1, and the discussion of
pseudo-destructor
calls in 5.2.4, to see why this code is incorrect.)
--
Summary: Misleading error message for ill-formed explicit
destructor invocation
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple 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=19243
[Bug c++/19044] Alternate asm name for atan ignored when calling __builtin_atan
--- Additional Comments From austern at apple dot com 2004-12-18 01:17
---
The code in the C front end that handles this is in finish_decl, in c-decl.c:
if (TREE_CODE (decl) == FUNCTION_DECL && asmspec)
{
if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
{
tree builtin = built_in_decls [DECL_FUNCTION_CODE (decl)];
set_user_assembler_name (builtin, asmspec);
if (DECL_FUNCTION_CODE (decl) == BUILT_IN_MEMCPY)
init_block_move_fn (asmspec);
else if (DECL_FUNCTION_CODE (decl) == BUILT_IN_MEMSET)
init_block_clear_fn (asmspec);
}
set_user_assembler_name (decl, asmspec);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044
[Bug c++/19044] New: Alternate asm name for atan ignored when calling __builtin_atan
For atan (and other functions like it), calling __builtin_atan is sometimes
supposed to fall back to the
library version of atan. In the C++ front end, this interacts poorly with
alternate asm names.
Consider the following test case:
#ifdef __cplusplus
extern "C"
#endif
double atan(double x) __asm("_fancy_atan");
double foo(double x) { return __builtin_atan(x); }
When it's compiled as C, it gives the behavior I expect: foo calls _fancy_atan.
The C++ front end,
however, gets it wrong: we call _atan, ignoring the fact that this function is
supposed to have a different
assembler name.
--
Summary: Alternate asm name for atan ignored when calling
__builtin_atan
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.6.0
GCC host triplet: powerpc-apple-darwin7.6.0
GCC target triplet: powerpc-apple-darwin7.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044
[Bug c/19041] New: -fvisibility=hidden causes bad codegen for common symbols
Compile the following file with -fvisibility=hidden
int foo;
void bar(void) { foo = 0; }
You will find that the assembler rejects the .s file that the compiler creates,
giving the error:
/var/tmp//cclfEVh7.s:16:non-relocatable subtraction expression, "_foo" minus
"L001$pb"
/var/tmp//cclfEVh7.s:16:symbol: "_foo" can't be undefined in a subtraction
expression
The assembler is right to complain. The compiler generates these lines:
addis r2,r31,ha16(_foo-"L001$pb")
la r2,lo16(_foo-"L001$pb")(r2)
This is incorrect. Common symbols must be treated as undefined symbols, so
they must be addressed
indirectly through non-lazy pointers. Without -fvisibility=hidden, the
compiler gets this right.
--
Summary: -fvisibility=hidden causes bad codegen for common
symbols
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.6.0
GCC host triplet: powerpc-apple-darwin7.6.0
GCC target triplet: powerpc-apple-darwin7.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19041
[Bug target/18964] New: Typo in visibility warning message
Compiling the following file on Darwin
void __attribute__((visibility("internal"))) foo() { }
gives the following error message:
foo.c:1: warning: internal and protected visibility attributes not supportedin
this configuration; ignored
This should be "supported in", not "supportedin".
--
Summary: Typo in visibility warning message
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.6.0
GCC host triplet: powerpc-apple-darwin7.6.0
GCC target triplet: powerpc-apple-darwin7.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18964
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From austern at apple dot com 2004-12-03 20:22
---
I don't think this is the most natural interpretation. The line
p = &((int) {1});
sets p to the address of the literal, and at the point we reach it for the
second time the literal itself has
been changed.
It might be useful to get an explicit ruling from the C committee, though. The
whole idea of changing
literals is sufficiently odd that it's hard to even talk about this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From austern at apple dot com 2004-12-03 19:27
---
Subject: Re: Incorrect reinitialization of compound literal
On Dec 3, 2004, at 11:15 AM, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org
> 2004-12-03 19:15 ---
> (In reply to comment #4)
>> Subject: Re: Incorrect reinitialization of compound literal
>>
>> On Dec 3, 2004, at 10:50 AM, pinskia at gcc dot gnu dot org wrote:
>>
>>>
>>> --- Additional Comments From pinskia at gcc dot gnu dot org
>>> 2004-12-03 18:50 ---
>>> But reading 6.5.2.5 P 16 seems to say something different.
>>>
>>> What it seems to say is:
>>> p = &((int) {1});
>>> is to set the int to be one and then take the address. We still
>>> point
>>> to the same int as before.
>>
>> Not exactly. We still point to the same (one-element) array of ints
>> we
>> did before. The array is modifiable, and we're changing the value of
>> the first element in the array. You might think that we should be
>> reinitializing the object, but that's wrong. When we execute that
>> statement a second time all we're doing is setting p to the address of
>> the compound literal again, but we have change the value of that
>> compound literal.
>
> But it is not clear to me at least we should reinitialize the literal,
> because the example which I gave
> shows it should but you say it should not.
The example you gave isn't relevant. It says that we don't create a
new object. It says nothing about modifying the original literal,
which is what we're doing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From austern at apple dot com 2004-12-03 18:59
---
Subject: Re: Incorrect reinitialization of compound literal
On Dec 3, 2004, at 10:50 AM, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org
> 2004-12-03 18:50 ---
> But reading 6.5.2.5 P 16 seems to say something different.
>
> What it seems to say is:
> p = &((int) {1});
> is to set the int to be one and then take the address. We still point
> to the same int as before.
Not exactly. We still point to the same (one-element) array of ints we
did before. The array is modifiable, and we're changing the value of
the first element in the array. You might think that we should be
reinitializing the object, but that's wrong. When we execute that
statement a second time all we're doing is setting p to the address of
the compound literal again, but we have change the value of that
compound literal.
It may sound odd to say that we're changing the value of a literal, but
C compound literals really are odd. 6.5.2.5 is quite explicit that
compound literals with modifiable types are modifiable.
The example in 6.5.2.5/16 is testing something completely different.
It checks to make sure that we're only creating the object once. My
test case checks for that (yes, we get that right; we only create the
object once) and also checks to make sure that changes in the object
are reflected correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] New: Incorrect reinitialization of compound literal
According to the ISO C standard, compound literals in functions are objects
with automatic storage
duration. The following test case modified such an object, so in this test
case the value should be 1 the
first time through the loop and 77 the second time. Instead we see 1 the first
time.
#include
int main() {
int i = 0;
int* p;
top:
p = &((int) {1});
printf("%p %d\n", p, *p);
*p = 77;
if (i++ == 0) goto top;
return 0;
}
--
Summary: Incorrect reinitialization of compound literal
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin
GCC host triplet: powerpc-apple-darwin
GCC target triplet: powerpc-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c++/18514] [3.4/4.0 Regression] Alternate "asm" name ignored for redeclared builtin function imported into namespace std
--- Additional Comments From austern at apple dot com 2004-11-29 20:56 --- Yep, I see what the problem is now. When we create a builtin in C++, we create the declaration in both the global namespace and namespace std. Later, when we see the declaration of snprintf in the global namespace, we correctly set the assembler name of ::snprintf. We don't set the assembler name of :: snprintf, since it's a separate declaration. Then we see the using-declaration, which is handled by do_nonmember_using_decl. It sees that we have an snprintf in namespace std already, verifies that :: snprintf and std::snprintf are compatible so this is not an error, and then just continues to use the original declaration of std::snprintf that was created by builtin_function. Nothing ever sets the assembler name of std::snprintf to match the one that got set for ::snprintf. So what to do about this? In principle, I think the answer is that builtin_function is doing something wrong by calling builtin_function_1 twice, once for the global namespace and once for namespace std. If we really must define all builtins in namespace std (what's the rationale?), then at least we should do it with a using-declaration instead of creating two entirely separate decls. This would help compile time performance a little bit: builtin_function_1 is just expensive enough to show up on profiles. If that's too radical a change given the current state of the compiler, then we could special-case builtins in do_nonmember_using_decl to make sure that the assembler name gets copied correctly. This wouldn't be hard. There's already some special-casing for builtins there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18514
[Bug other/18555] Need a command line switch to control gcc's include and libary finding mechanism
--- Additional Comments From austern at apple dot com 2004-11-18 21:39 --- We have a lot of options that are vaguely similiar to this. It's also reminiscent of -iprefix. But I actually think the closest analogy is to -B. Its effect on header and library paths is the same as -B, but it doesn't change the search for compiler executables. And while Syd is right that Apple would find this feature useful, I don't think there's anything about it that's specific to Apple or Darwin. I expect it to be generally useful for people who are trying to deal with multiple similar-but-not-identical versions of an operating system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18555
[Bug c/18523] New: Documentation should discuss removal of generalized lvalues
gcc 4.0 has a new feature: it no longer recognizes generalized lvalues. The
documentation doesn't say
anything about it, however. Instead, the section on generalized lvalues from
3.4 has just been
removed.
This isn't reasonable. Users who are familiar with previous versions of GCC
shouldn't have to do an
exhaustive search through the documentation to find that something isn't there,
and then interpret the
absence from the documentation correctly, in order to learn of such a major
change. The
documentation should clearly say that generalized lvalues have been removed,
and should give users
advice on how to fix older code that relied on this extension.
--
Summary: Documentation should discuss removal of generalized
lvalues
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple 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=18523
[Bug c++/18522] New: Error message formatted badly
[isolde:tmp]$ cat > a.cc
int foo();
void bar() { &foo(); }
[isolde:tmp]$ /work/root/bin/g++ -c a.cc
a.cc: In function 'void bar()':
a.cc:2: error: non-lvalue in unary %<&$>
[isolde:tmp]$
We don't really want users to see that "%<" junk, do we?
--
Summary: Error message formatted badly
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.6.0
GCC host triplet: powerpc-apple-darwin7.6.0
GCC target triplet: powerpc-apple-darwin7.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18522
[Bug c++/18514] New: Alternate "asm" name ignored for function imported into namespace std
Compile the following test case:
extern "C" {
typedef unsigned long size_t;
int snprintf(char * , size_t, const char * , ...) __asm("_fancy_snprintf");
}
namespace std { using ::snprintf; }
namespace std { void foo() { snprintf(0, 3, ""); } }
If you examine the assembly file or the .o file, you will see that we're
invoking _snprintf. This is wrong.
We should be invoking _fancy_snprintf.
Note that it's important that we're importing into namespace std. If I change
the name to something
else, the problem goes away.
--
Summary: Alternate "asm" name ignored for function imported into
namespace std
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.6.0
GCC host triplet: powerpc-apple-darwin7.6.0
GCC target triplet: powerpc-apple-darwin7.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18514
[Bug c++/18165] New: Attributes following enumeration declaration ignored
Consider the following program:
m>
enum X { a = 1 };
enum Y { b = 1 } __attribute__((packed));
int main()
{
using namespace std;
cout << "default:" << sizeof(enum X) << endl;
cout << "with attribute: " << sizeof(enum Y) << endl;
}
The C++ compiler accepts this. However, the attribute on enum Y is ignored. As
running this program
shows, the size of enum Y is the same as the size of enum X.
Note that the test suite contains a test to make sure that an attribute in this
position is accepted.
(parse/parse3.C) We just failed to make sure that the attribute really did anything.
--
Summary: Attributes following enumeration declaration ignored
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.5.0
GCC host triplet: powerpc-apple-darwin7.5.0
GCC target triplet: powerpc-apple-darwin7.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18165
[Bug c++/18150] New: Should enable -Wsequence-point for C++
-Wsequence-point is documented to be C-only. However, it would be just as useful for C++ as it is for C. We should implement -Wsequence-point for C++. -- Summary: Should enable -Wsequence-point for C++ Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: austern at apple 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=18150
[Bug c++/17542] Visibility attribute ignored when it precedes class head
--- Additional Comments From austern at apple dot com 2004-10-01 23:22 ---
Actually, this is almost straightforward. It has nothing to do with the visibility
attribute: it has to do
with attributes and C++ classes in general. Looking at cp_parser_class, and
especially at
cp_parser_class_head, attributes can appear in one of two places. The parser will
recognize either
struct __attribute__((visibility("hidden"))) foo { virtual ~foo(); };
or
struct foo { virtual ~foo(); } __attribute__((visibility("hidden")));
But, as the code and the comments both make quite clear, the syntax we're recognizing
does not
include an attribute list before the class-key.
So then how come the __atrtribute__ is being swallowed and ignored? Answer: what
we've got here is a
simple-declaration with two decl-specifiers, an attribute list and a class definition,
and no declarators.
The attribute list applies to a declarator, which in this case is missing. We could
instead have written:
__attribute__((visibility("hidden"))) struct foo { virtual ~foo() { } } x;
In this case we can see that the attribute isn't being ignored; it just applies to x,
not to foo.
I hesitate to call this "behaves correctly", since this behavior is unexpected, hard
to understand, and
leads to the user silently not getting what they expected. I'm afraid that with
visibility, in particular, it'll
lead to problems because users will want to hide this attribute list behind macros
that expand to
different things on different platforms. But I'm also not completely sure what the
best thing to do is.
Here are my two two choices:
1. Special-case this construct. If a simple-declaration consists of a class
definition with no declarator,
then any attributes preceding the class head get applied to the class.
2. If cp_parser_simple_declaration collects attributes in
cp_parser_decl_specifier_seq and it's throwing
them away because there's no declarator to apply them to, then warn the user and
suggest a better
place to put the attribute list.
Option 1 is admittedly a hack, but that doesn't necessarily mean it's a bad idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17542
[Bug c++/3471] gcc 3.01 reports error about a private copy constructor that shouldn't get called.
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3471 --- Additional Comments From austern at apple dot com 2003-09-09 18:00 --- I believe that this resolution is incorrect. f.test(b) initializes a reference of type const foo& with a temporary, where the temporary was created via a user-defined conversion from bar, foo::foo(bar). The last bullet item in section 8.5.3/p5 of the standard (i.e. the bullet item just before par 6) says that the temporary is created "using the rules for a non- reference copy initialization (8.5)". 8.5p14 says that non-reference copy initialization is done as if by doing a user-defined conversion and then making a copy. It says that an implementation is permitted to elide the copy constructor, referring to clause 12.2 for details. 12.2 paragraph 1 makes it clear that even when the copy constructor is elided, the implementation is still required to check it for accessibility. I've opened new bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12226 for the failure to check copy constructor accessibility when the copy constructor is optimized away.
