Re: [Bug c++/34015] warning in backward_warning.h is illegible
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | We cannot assume that people encountering the warning will have web access. That is true. But, the majority of for those who do have a web access, we should provide additional pointers. Of course, the real solution is to leave these headers as they were in previous GCC releases. -- Gaby
Re: [Bug c++/29365] Unnecessary anonymous namespace warnings
Andrew Pinski [EMAIL PROTECTED] writes: | On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org | [EMAIL PROTECTED] wrote: | It is a good question in itself whether pimpl_ has a type at all -- it's a | pointer to an incomplete type in any case :-) | | All types in C++ are exported (well except for anonymous namespace | types) including incomplete types. What does not could mean in C++? -- Gaby
Re: [Bug c++/33124] New: C++ frontend should not warn about new a[0] in template context
ian at airs dot com [EMAIL PROTECTED] writes:
| For this simplified code:
|
| templateint c
| char* f1() { if (c == 0) return 0; else return new char[c]; }
| char* f2() { return f10(); }
|
| the C++ frontend issues an unconditional warning. When compiling with no
| options, I get
|
| foo.cc: In function char* f1() [with int c = 0]:
| foo.cc:3: instantiated from here
| foo.cc:2: warning: allocating zero-element array
|
| I have no objection to this warning in ordinary usage, but when the argument
to
| new[] depends on a template parameter, I think this warning does more harm
than
| good. Even with properly parameterized code we get a useless and unavoidable
| warning.
|
| I recommend both 1) don't warn when the argument depends on a template
| parameter; and 2) add an option to control this warning.
I think that, in general, for template instantiations it makes perfect
sense to warn -- because after all, the user may want to know off-hand
that the instantiation is invoking an undefined behaviour.
However, in this specific case, simple control can determine that the
branch is never executed, therefore the warning is unwarranted.
The fix to this PR should not stop warning for template instantiation;
it should take into account simple data-flow control-flow into
account.
The problem is not just with templates; it is directly related to our
coding convention of saying
if (HAVE_FEATURE)
{
// ...
}
else
{
// ...
}
where HAVE_FEATURE is a macro expanding to a constant. We don't want
to unconditionally warn for both branches.
-- Gaby
Re: [Bug c++/32984] New: add checking for array new delete
dcb314 at hotmail dot com [EMAIL PROTECTED] writes:
| Given the following C++ code
|
| class K
| {
| public:
| void f();
| void g();
|
| private:
| int * a;
| double * b;
| float * c;
| unsigned int * d;
| };
|
| void K :: f()
| {
| a = new int;
| b = new double [ 10];
| delete c;
| delete [] d;
| }
|
| void K :: g()
| {
| delete [] a;// error
| delete b; // error
| c = new float [ 20];// error
| d = new unsigned int; // error
| }
|
| Recent snapshot g++ 4.3 20070803 can't find anything
| wrong with the code.
Special, dedicated tools exist for that task. I would suggest
you use one of them.
The above should not be the business of the *compiler*.
-- Gaby
Re: [Bug c++/32984] add checking for array new delete
dcb314 at hotmail dot com [EMAIL PROTECTED] writes: | The compiler can generate a whole bunch of warnings | already. Which fall in different mindset that the one you would like. -- Gaby
Re: [Bug c++/32525] Request for new warning: useless dynamic_casts
lloyd at randombit dot net [EMAIL PROTECTED] writes: | I think that's a good definition. My impression is that dynamic_cast is fairly | expensive, well, I don't think GCC should be getting into the business of warning about expensive operations. -- Gaby
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
| new does not change the dynamic type as it should
|
| rguenth at gcc dot gnu dot org wrote:
|
| - we _cannot_ sink loads across stores.
|
| x = *int;
| *double = 1.0;
|
| the store to double may change the dynamic type of what *int
| points to.
|
| To be clear, you mean something like this, right:
|
| int i;
| int *ip = i;
| double *dp = (double *)i;
| int x;
| x = *ip;
| *dp = 1.0;
|
| ?
|
| I think that considering this code valid, and, therefore, forbidding the
| interchange of the last two statements, requires a perverse reading of
| the standard.
I'm not sure Richard is suggesting that -- I believe, we all agree
that the above is invalid. It introduces an assumption that was not
present in Richard's previous message (Richard might want to make
explicit his assumptions). Namely, that we do know the definition of
of the object
int i;
therefore we know that we can not possibly change its dynamic type.
Consider the following instead
// tu-1.C
void f(int* p) {
*p = 90;
// ...
*(double *) p = 8.3748;
};
Is the above code invalid, independent of context? I don't think
you can find a wording in the standard that says it is invalid.
Indeed, consider this:
// tu-2.C
void f(int*);
void g() {
union {
int i;
double d;
} t;
t.i = 42;
f(t);
cout t.d endl;
}
I believe we can all agree the definition of g is valid.
-- Gaby
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Indeed, consider this:
|
| // tu-2.C
| void f(int*);
| void g() {
|union {
| int i;
| double d;
|} t;
|
| t.i = 42;
| f(t);
| cout t.d endl;
| }
|
| I believe we can all agree the definition of g is valid.
|
| No, I do not. And GCC historically has not; you are only allowed to use
| the union for type-punning if the accesses are through the union
| directly.
I am not talking of the GCC's historical behaviour here, but what the
standard actually says. For the object t, above the last write was
to the double field, therefore the read is well-defined.
-- Gaby
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes: | But, I don't think the standard contemplated | these issues in sufficient detail to make it useful in this respect. The issues has been raised on the -core reflector. -- Gaby
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
ian at airs dot com [EMAIL PROTECTED] writes: | I'm not sure what to make of comment #84. We don't determine aliasing by | alignment or size. We determine it by type. We don't currently treat int and | long as aliasing each other even if they happen to have the same alignment and | size. That is GOOD. :-) | I believe this is correct according to the C standard but I am less | familiar with the C++ standard. It is also correct semantics with respect to C++. C++ goes further (I don't have C standard handy to check). The memory pointed to by p must have the right alignment requirements etc. So if you grab memory into p and it does not have the right alignment, then the new placement yields undefined behaviour. That is not a property we can check statically (until we get the alignment proposal into C++). | We could change the aliasing machinery in that | way for C++ if it seems to be appropriate, but I would prefer to take that to a | different PR. What I was trying to say was that C++ provides the same dynamic type (non-)aliasing guarantees, and goes even further. Did I manage to confuse you again? -- Gaby
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
ian at airs dot com [EMAIL PROTECTED] writes:
| But I don't think that is the question at hand. The variable is always being
| accessed in the same type, which is also the type of its declaration. The
| question at hand is this:
|
| void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
| void g() { int i; f((double *)i); }
|
| And the specific question is whether we are permitted to interchange the
| assignments to *p and *l.
After the placement new, the lifetime of *p is ended, and the lifetime
of *l starts there. I don't think that leaves room for exchanging the
stores to *p and *l.
| Let's consider this:
|
| void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
|
| Is that valid?
If p is pointing to a union object that contain both int and long,
yes, it is valid. Otherwisem, it is not.
| Is the compiler permitted to interchange the assignments to *p
| and *l?
It is valid if we have a union object, otherwise, no.
-- Gaby
Re: [Bug c++/31505] [4.3 Regression] Canonical types failures
bangerth at dealii dot org [EMAIL PROTECTED] writes: | Talking about canonical types: I think the idea of only issuing a warning | in cases like the current one is a really bad idea. Fully agreed. I believe we discussed this on the main list. It should not be a warning. It should be an ICE. This is a compiler bug. That is what ICE is for. -- Gaby
Re: [Bug c++/99] Bug in template type in error message.
bangerth at dealii dot org [EMAIL PROTECTED] writes: | Still happens with a recent mainline snapshot. This one is tricky. I once had a patch for it, but then the patch broke some other diagnostic. :-( I'll try to revive it. -- Gaby
Re: [Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #10) | | I fully agree. | | I am not agreeing fully, Well, you've got a problem. [...] | What about this case: There is a distinction betwen user code and compiler-generated codes. Warning about compiler-generated codes is pointless. -- Gaby
Re: [Bug c++/31187] New: [4.2 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
zak at transversal dot com [EMAIL PROTECTED] writes:
| The following code, which compiles fine on gcc 4.1.2 and I believe is valid,
| fails on an up-to-date checkout from the 4.2 branch:
|
| --
| class foo { };
|
| namespace
| {
| extern foo foo1;
| foo foo1;
| }
|
| template foo *
| class bar { };
|
| bar foo1 bar1;
| ---
|
| giving the error:
|
| test.cc:12: error: 'unnamed::foo1' is not a valid template argument of type
| 'foo*' because 'unnamed::foo1' does not have external linkage
| test.cc:12: error: invalid type in declaration before ';' token
|
|
| ... which I would only expect if foo1 were declared static.
Yes, this is a bug in the compiler. I suspect it was introduced when
the the back was told to treat declarations at unnamed namespaces
ast static. That of course is an optimization and should be appear at
the front-end.
-- gaby
Re: [Bug c++/30734] New: name conflict between class and namespace name is not recognized
ulrich dot lauther at siemens dot com [EMAIL PROTECTED] writes:
| 1 namespace Foo {
|2 };
|3
|4 class Foo {
|5 };
|6
|7 int main() {
|8class Foo1 : public Foo {
|9};
| 10Foo1 my_Foo1;
| 11Foo my_foo;
| 12return 0;
| 13 }
| 14
| 15
| Foo.C: In function 'int main()':
| Foo.C:11: error: expected primary-expression before 'my_foo'
| Foo.C:11: error: expected `;' before 'my_foo'
|
| on line 8 and 10, Foo is understod asa class name, on line 11 as a namespace
| Without line 11, no error message at all
Line 4 is invalid; the front-end should have issued a diagnostic there.
-- Gaby
Re: [Bug c++/30245] New: -O2 generates bad code
dcb314 at hotmail dot com [EMAIL PROTECTED] writes:
| I compiled the following C++ code on a x86_64 machine
| without optimisation.
|
| #include iostream.h
|
| int
| main()
| {
| long long n = 1;
|
| cout sizeof( n) endl;
| for (int i = 0; i 100; ++i)
| {
| cout n ' ' (float) n '\n';
| n *= 2;
| if (n == 0)
| {
| break;
| }
| }
| return 0;
| }
|
| When the compiled code runs, it is fine.
| There are 64 executions of the loop.
|
| However, I added flag -O2, and the code runs differently.
| There are 100 executions of the loop.
|
| Suspect optimiser bug.
Rather, user bug.
Your program contains an undefined behaviour which is provoked by the
overflow of n *= 2; the compiler is therefore technically allowed to
do whatever it likes. In this case, the optimizer assumes that you
can never get from 1 to 0 by successive exponentiation. Therefore the
test n == 0 is never executed.
-- Gaby
Re: [Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes: | --- Comment #22 from mark at codesourcery dot com 2006-10-04 05:39 --- | Subject: Re: [4.0/4.1/4.2 Regression] placement new | does not change the dynamic type as it should | | ian at airs dot com wrote: | --- Comment #21 from ian at airs dot com 2006-10-03 23:44 --- | In C a general allocation function should work with a char array. A specific | allocation function should use a union. I don't think there are many existing | exceptions to these guidelines. | | So I don't see a serious problem in C either. Am I missing something/ | | I think there are two remaining issues: | |int i; |*(float*)(i) = 7.0; | | IIUC, Mike's position is that this is valid -- and that, in fact, after | this point i can no longer be accessed as an int. Do you agree? I don't see how that code is supported by the paragraphs quoted by Mike. There was a recent discussion (at most two weeks ago) on the C++ standard reflector -core about similar topic. I do agree with Mark that the proper way to resolve this is to go to the C++ committee. It would be incredible that C++ was less type-strict than C. -- Gaby
Re: [Bug libstdc++/6257] C-library symbols enter global namespace
marc dot glisse at normalesup dot org [EMAIL PROTECTED] writes: | (In reply to comment #20) | the | very same source code would not be be portable across those targets. I don't | think we would like that. Besides, more generally, I'm not at all sure that | all the users would actually *like* the new behavior. | | I meant proposing it as a choice, with a flag like -fclean-global-namespace That is a non-starter. PR better suspended. -- Gaby
Re: Typecast bug
[EMAIL PROTECTED] writes: | On 26 Apr 2006, Gabriel Dos Reis wrote: | | [EMAIL PROTECTED] writes: | | | It is gcc 4.1.0, --target=arm-elf compiled on an Intel platform and | | GNU/Linux. | | | | The following construct: | | | | void *p; | | | | ((char *)p)++; | | | | makes the compiler to issue an error message, namely | | invalid lvalue in increment | | | | The ((char *)p) construct is perfectly valid object, a char pointer which | | can be lvalue and rvalue alike. For some reason gcc 4.1.0 (and 4.0.2 as | | well) treats ((SOME_TYPE *)p) as if it could not be an lvalue; | | indeed, it is not; in any ISO C version I know of. | | OK - my bad. Wrote first thought later. Old gcc accepted the construct and | legacy code broke on the new compiler. My sincere apologies. | | The question, however, remains: (how) can I tell the compiler to treat a | pointer declared as void *p; as if it was a SOME_TYPE *p pointer without | introducing temporaries? You have to use a cast, and the result is not an lvalue. Period. Or, use the original pointer SOME_TYPE *p. -- Gaby
Re: Typecast bug
[EMAIL PROTECTED] writes: | It is gcc 4.1.0, --target=arm-elf compiled on an Intel platform and | GNU/Linux. | | The following construct: | | void *p; | | ((char *)p)++; | | makes the compiler to issue an error message, namely | invalid lvalue in increment | | The ((char *)p) construct is perfectly valid object, a char pointer which | can be lvalue and rvalue alike. For some reason gcc 4.1.0 (and 4.0.2 as | well) treats ((SOME_TYPE *)p) as if it could not be an lvalue; indeed, it is not; in any ISO C version I know of. -- Gaby
Re: [Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED] writes: | ( As an aside that suggests that you could have a strictly conforming | implementation where the max limit is 0, but that discussion is more fitting on | comp.std.c++) That is technically correct; but it is beside the point. -- Gaby
Re: [Bug libstdc++/25608] g++ miscompiles gcjx
bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes: | is this still an active issue, or was it indicative of some temporary or | transient thing in the gcc sources? Now, I get a segmentation fault -- instead of dead lock. gcjx is compiled with mainline GCC/g++. I was trying to compile classptah. Adding generated files in builddir '..'. /home/gdr/bin/gcjx -encoding UTF-8 -classpath .: -d . @classes make[1]: *** [compile-classes] Segmentation fault make[1]: Leaving directory `/home/gdr/build/classpath/lib' -- Gaby
Re: [Bug c++/26395] Wrong attempts to create a copy of an anonymous object
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-21 15:59 --- | Please read: | http://gcc.gnu.org/gcc-3.4/changes.html | | | GCC before 3.4 was accepting invalid code. | | | -- | | pinskia at gcc dot gnu dot org changed: | |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||INVALID In fact, there should be an open PR for this -- which is a request for enhancement. The code is ill-formed under C++98 and C++03; it is well formed in C++0x (the changes are in the Working Paper.) -- Gaby
Re: [Bug c++/25625] [4.0/4.1/4.2 Regression] Fails to compile C++ code when -frepo is specified.
pault at gcc dot gnu dot org [EMAIL PROTECTED] writes: [...] | URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110310 | Log: | 2005-01-28 Paul Thomas [EMAIL PROTECTED] | | PR fortran/25964 | * resolve.c (resolve_function): Exclude statement functions from | global reference checking. Can someone explain me why a fortran commit shows up as a C++ releated commit? -- Gaby
Re: [Bug c++/25927] New: Spurious offsetof warnings with private members
rcbilson at plg dot uwaterloo dot ca [EMAIL PROTECTED] writes:
| Consider:
|
| #include iostream
| #include cstddef
|
| class xxx {
| friend int main();
| void *q;
| public:
| void *r;
| };
|
| int main() {
| std::cout offset of xxx::q is offsetof( xxx, q ) \n;
| std::cout offset of xxx::r is offsetof( xxx, r ) \n;
| return 0;
| }
|
| The class xxx is POD, and the two applications of offsetof should be ok (per
| 18.1p5).
No, the class xxx is not a POD because xxx::q is non-public. Invalid
PR, should be closed.
-- Gaby
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
sigra at home dot se [EMAIL PROTECTED] writes: | std::cout static_castunsigned short(t) std::endl; | } | | If static_castconst unsigned short would work, the compiler should warn. given call-by-value, you must be joking. -- Gaby
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
sigra at home dot se [EMAIL PROTECTED] writes:
| --- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
| On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
|
| --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
| ---
| (In reply to comment #3)
| const does nothing when it comes to local variables except for not
| letting you
| touch it in other expressions. It does nothing for optimizations or
| anything
| else.
|
| This last point is not obvious at all, in my opinion. Why not? In
| principle,
| certainly const-ness *can* help optimizers one way or the other. Is
| this just a
| current limitation? A design choice? Anything in the standard making
| that
| tricky? I would like to know more.
|
|
| int f(const int *a, int *b)
| {
| *b = 1;
| return *a;
| }
|
| a and b can alias and there is no way around that at all because that is
| what the C++ standard says.
|
| In this case the compiler should warn because a could be declared const int *
| const and b could be declared int * const.
It does not make any sense to require the compiler to give a warning
in that case.
-- Gaby
Re: [Bug c++/25826] New: pure virtual destructors accepted by GCC, but cause link failure
lloyd at randombit dot net [EMAIL PROTECTED] writes:
| The following code:
|
| class A
|{
|public:
| virtual ~A() = 0;
You still need to *define* the destructor. See §12.4/7.
-- Gaby
Re: [Bug bootstrap/25455] [4.2 Regression] make all with a native build now does a bootstrap instead of a normal build
Andrew Pinski [EMAIL PROTECTED] writes: [...] | But he did not which is why there is a bug report. At this moment, I guess the most important thing is that how to make is clarified and Paolo is willing to fix any problem that might result from his change. I'm doing what Daniel J. requested and I'll post the log once the build is finished. -- Gaby
Re: [Bug c/25301] New: [3.4 regression] ICE for sizofe of incomplete type
reichelt at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch.
| A reduced testcase is:
|
| ===
| typedef struct A B;
| int i = sizeof(B);
| ===
|
| bug.c:2: error: invalid application of `sizeof' to incomplete type `
| Internal compiler error: Error reporting routines re-entered.
| Please submit a full bug report, [etc.]
|
| The culprit is the code in c-objc-common.c (c_tree_printer) case 'T':
|
| case 'T':
| if (TREE_CODE (t) == TYPE_DECL)
| {
| if (DECL_NAME (t))
| n = (*lang_hooks.decl_printable_name) (t, 2);
| }
| else
| {
| t = TYPE_NAME (t);
| if (t)
| n = IDENTIFIER_POINTER (t);
| }
| break;
|
| In the above case t is a RECORD_TYPE, but TYPE_NAME (t) is a TYPE_DECL.
| So there's some logic missing to handle this case.
In general, there is a type problem in both C and C++ front ends.
The documentation for TYPE_NAME says that it returns a TYPE_DECL -- as
opposed to an IDENTIFIER_NODE. However, at various occasions I found
that a TYPE_NAME would return an IDENTIFIER_NODE. That is a clear bug
in both front ends ans should be hunt. Obviously, you have identified a
place where instead of correcting the problem the pretty-printer had
assumed that TYPE_NAME will always return an IDENTIFIER_NODE --
despite the documentation. I believe a proper PR should be filled so
that both front ends are cured from that confusion.
-- Gaby
Re: [Bug c++/24983] Needs a warning?
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | earth:~~/ia32_linux_gcc3_0/bin/gcc t.cc | t.cc:2: prototype for `void foo::f()' does not match any in class `foo' | t.cc:1: candidate is: const void foo::f() | earth:~~/ia32_linux_gcc2_95//bin/gcc t.cc | t.cc:2: new declaration `void foo::f()' | t.cc:1: ambiguates old declaration `const void foo::f()' | | | I say that 3.0.x is the best if it is what we should say then we have a | regression. We should say: 'const void' is not a valid type and be done with it. -- Gaby
Re: [Bug c++/24103] [3.4 Regression] ICE in simple_cst_equal
janis187 at us dot ibm dot com [EMAIL PROTECTED] writes: | A regression hunt for the patch that fixed this on mainline identified the | merge of the tree-ssa branch. Thanks. That would indicate that if we're unable to find a minimal patch, then we would just have to close it as WONTFIX. -- Gaby
Re: [Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code
mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] writes: | The problem behind both diagnostics fact that the C++ front-end pre-lexes the | entire source file. As a result, the lexing routines, which depends on the | setting of pedantic to determine whether or not to issue errors, are | called when pedantic is set, even though we are within an | __extension__ block. Because the parsing of __extension__ blocks is | complex, we need to either (a) eliminate the up-front lexing, or (b) | defer issuing diagnostics until we are actually in | position to know the correct value of pedantic. In long term, I believe (b) is a better alternative. -- Gaby
Re: [Bug c++/23689] Malformed typedef silently ignored
falk at debian dot org [EMAIL PROTECTED] writes: | Works for me with any gcc version: | | [EMAIL PROTECTED]:/tmp% gcc-3.4 -c test.c | test.c:1: warning: useless keyword or type name in empty declaration | test.c:2: warning: useless keyword or type name in empty declaration | | What is the exact version you are using and the exact flags you are passing? The bug was reported against C++; I believe you're testing with a C compiler, instead of C++. -- Gaby
Re: [Bug c++/23156] New: Fails valid? (valid according to Comeau anyway)
igodard at pacbell dot net [EMAIL PROTECTED] writes:
| typedef int A;
| struct foo{
| A A;
| };
|
| compiles in 3.4.0 and on Comeau, but on 3.4.2 you get:
The code is ill-formed; no diagnostic required. GCC-3.x, x 4 used to
issue a diagnostic as a QoI. A regression was introduced in 3.4.0,
and fixed later.
| changedMeaning.cc:3: error: declaration of `A foo::A'
| changedMeaning.cc:1: error: changes meaning of `A' from `typedef int A'
|
| So who's right, you or EDG?
Both, but we're better ;-)
-- Gaby
Re: [Bug c/22278] gcc -O2 discards cast to volatile
neroden at gcc dot gnu dot org [EMAIL PROTECTED] writes:
[...]
| of an arbitrary memory address. If the underlying object has
| to be volatile, how do we make it volatile? Can we simply create a new
| underlying object by throwing in a temporary pointer variable? Is
something
| like the following sufficient to force an access?
|
| static inline unsigned char myMmioIn8(volatile void* base,
| const unsigned long offset)
| {
| volatile CARD8 * tmp = (CARD8*)base + offset;
| return *tmp;
| }
If is fragile. If the compiler does more aggressive inline (which I
hope 4.0 doesn't, but 4.x may at some point) and discover that the
chains of conversion started with something it thinks really not
volatile, then it would behave the same way as with the macro.
| # define MMIO_IN8(base, offset) myMmioIn8(base, offset)
|
| If that's not sufficient, I don't see any way to accomplish the required
| behavior under gcc 4.0 (without massive rewriting of the X.org code), so I
| hope it is.
I've come to believe that GCC's current choice is needlessly
unhelpful. I think it is much more reasonable to have GCC leave its
optimizer fingers out of the access through volatile lvalue, whether
the object behind is really defined volatile of not -- GCC cannot
know and the programmer cannot if is the object behind is actually
never defined, but is mapped to a memory. Unfortunately, I don't know
the extent of the GCC code that needs to be fixed so I don't know
whether it is fixable in 4.0.
-- Gaby
Re: [Bug c++/22452] [4.1 regression] ICE expected tree that contains 'decl with visibility' structure, have 'const_decl' in decl_linkage, at cp/tree.c:2132
dberlin at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Nathan tells me it's lk_internal for a CONST_DECL. Where does that come from? There is a section numbered 3.5 and titled Program and linkage. It says in paragraph 4 A name having namespace scope has external linkage if it is the name of -- an object or reference, unless it has internal linkage; or -- a function, unless it has internal linkage; or -- a named class (clause 9), or an unnamed class defined in a typedef declaration in which the class has the typedef name for linkage purposes (7.1.3); or -- a named enumeration (7.2), or an unnamed enumeration defined in a typedef declaration in which the enumeration has the typedef name for linkage purposes (7.1.3); or -- an enumerator belonging to an enumeration with external linkage; or -- a template, unless it is a function template that has internal linkage (clause 14); or -- a namespace (7.3), unless it is declared within an unnamed namespace. And in paragraph 8, it continues: Names not covered by these rules have no linkage. Moreover, except as noted, a name declared in a local scope (3.3.2) has no linkage. A name with no linkage (notably, the name of a class or enumeration declared in a local scope (3.3.2)) shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered. those clearly indicates to me that the linkage of a CONST_DECL depends on the linkage of its enumeration. | fixing. Please look at section 3.5 before fixing this. (besides an numeration does not have storage). -- Gaby
Re: [Bug c/22485] pointer +- integer is never NULL
falk at debian dot org [EMAIL PROTECTED] writes: | --- Additional Comments From falk at debian dot org 2005-07-14 15:37 --- | (In reply to comment #7) | | I'm failing to find anything in the C++ standard that suggests that the | following shall be undefined | | (reinterpret_castint*(0) + 5) - 5 | | If (reinterpret_castint*(0) + 5) - 5 is not undefined, then neither is | reinterpret_castint*(0) + 5. Then what is its result, by which paragraph | in the standard? The standard says that the mapping used by reinterpret_cast to turn an integer into a pointer is *implemented-defined*. It is not undefined. GCC uses the obvious mapping, which is reinterpret_castint*(0) is the null pointer. -- Gaby
Re: [Bug c++/22452] [4.1 regression] ICE expected tree that contains 'decl with visibility' structure, have 'const_decl' in decl_linkage, at cp/tree.c:2132
dberlin at dberlin dot org [EMAIL PROTECTED] writes: | --- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-14 20:40 --- | Subject: Re: [4.1 regression] ICE expected tree that | contains 'decl with visibility' structure, have 'const_decl' in | decl_linkage, at cp/tree.c:2132 | | | | | | I really don't have the skills to play language lawyer here, my | | I'm not here to play language lawyer neither; but the claim just looks | wrong to me. Unless you define playing language lawyer as giving | asnwer you questions you raised. | Playing language lawyer is sitting here quoting the standard at me | instead of demonstrating a testcase where the old answer is wrong. The comment in front of DECL_EXTERNAL_LINKAGE_P says this: /* Returns nonzero if DECL has external linkage, as specified by the language standard. (This predicate may hold even when the corresponding entity is not actually given external linkage in the object file; see decl_linkage for details.) */ #define DECL_EXTERNAL_LINKAGE_P(DECL) \ (decl_linkage (DECL) == lk_external) So, if you find a testcase where decl_linkage() returns lk_internal insteand of lk_external, then you have found a bug in the compiler. The fix is not to copy-and-paste that error. Language lawyering notwithstanding. -- Gaby
Re: [Bug c/22278] gcc -O2 discards cast to volatile
gdr at integrable-solutions dot net [EMAIL PROTECTED] writes:
| | Still, consider the following variant:
| |
| | void quux(int *bar) {
| | *(volatile int*)bar = 42;
| | }
| |
| | volatile int foo;
| | quux((int*)foo);
| |
| | This time there is no attempt [...] to refer to an object defined with a
| | volatile-qualified type through use of an lvalue with non-volatile-qualified
| | type.
|
|
| Really?
that comment is wrong, sorry. You're right. (time for me to go to bed).
Yes, this is a bug in GCC.
-- Gaby
Re: [Bug c/22278] gcc -O2 discards cast to volatile
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html. Both those issues about completely *different* from the issue submitted in this PR. In the above cases, the accessed object actually is NOT volatile. This is not the same here. In this PR, the only thing the function sees is that its parameter is not declared pointer to volatile char, but just pointer to char. That is NO basis for the compiler to assume that the cast performed inside the body is invalid assumption. No. Never. Consequently, it must assume that the pointed-to object might be effectively volatile and consequently generate corresponding code. There is a difference between cv-qualified object and a pointer to cv-qualified object. In the former cases, you do know for sure how the object behaves, in the latter you don't. Consequently you must make conervative assumptions. |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||DUPLICATE Andrew -- Once again, refrain from closing an issue when you do not fully understand the issue at hand. The PR should be reopen as wrong-code generation. -- Gaby
Re: [Bug c/22278] gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | --- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30 --- | (In reply to comment #17) | Furthermore, the fundamental issue is whether this | | *(volatile int*) (int*) (foo); | | (or equivalent) where foo has been defined volatile int should be | treated differently from | | *(volatile int*) (foo); | | or | | foo; | | How about this? | | int foo; | *(volatile int*) (foo); It was included in my previous message. | In other words, why should the compiler bother at all with the qualifiers of | what the pointer really points to? Because the language definition says that the compiler should preserve a semantics and the compiler better bothers. | It seems simplest and most natural to | decree that any dereference of a pointer-to-volatile (regardless of | its origin) is to be treated as volatile and thus never optimized | away. In other words, volatile should treated as a property of the | type of the pointer being dereferenced, not of the actual object | being pointed to. but that is a fundamental departure from the language semantics. Replace volatile with const -- both are qualifiers -- and observe the disaster that would ensue. The volatile cv-qualified is interesting in the sense that it is fuzzily defined, but there are identities that the compiler must preserve. -- Gaby
Re: [Bug c/22278] gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| (In reply to comment #30)
| | OK. Then the volatile-stripping direction can be handled arbitrarily.
|
| I do not understand that comment.
|
| I meant that we were mostly concerned about what the standard says about the
| effect of casting (say) int* into volatile int*, but the other directly is
| simply undefined.
That is what I do not understand. Could you point me to the relevant
passage of the C standard?
| Still, consider the following variant:
|
| void quux(int *bar) {
| *(volatile int*)bar = 42;
| }
|
| volatile int foo;
| quux((int*)foo);
|
| This time there is no attempt [...] to refer to an object defined with a
| volatile-qualified type through use of an lvalue with non-volatile-qualified
| type.
Really? What does quux() does to the object defined through foo then?
| So why does gcc 4.0.0 -O3 still optimize away the assignment? And how
| would you fix that with an approach that construes the standard to require
| following the type of the real object?
|
| Could the standard intend something so convoluted, when the interpretation in
| comment 23 makes things perfectly sensible, well-defined and (in principle)
easy
| to implement?
My understanding is that you have gotten everything backwards.
-- Gaby
Re: [Bug c++/22248] New: Incorrect work with multiple assigment.
algorithmus at gmail dot com [EMAIL PROTECTED] writes: | ---new.cpp | #includecstdio | | #define swap(a,b) a^=b^=a^=b You're modifying objects more than once without intervening sequence points. All bets are off. There is a standard utility std::swap() from utility that works all the time. PR invalid. -- Gaby
Re: [Bug c++/22256] diagnostic shows wrong type for cast operator
igodard at pacbell dot net [EMAIL PROTECTED] writes:
| Gabriel: no, it also happens with any pointer:
|
| struct node { float*operator float*(); };
|
| gets you:
|
| foo.cc:1: error: operator `float*' declared to return `float'
Alright, that was a wrong guess.
-- Gaby
Re: [Bug c++/22227] New: g++ 4.0.0 has issues with the typedef of reference
jcurran2 at uiuc dot edu [EMAIL PROTECTED] writes: | G++ thinks that a nested type is a nested class and it expects a constructor, | destructor, or type conversion before the object referenced in the class is | processed when compiling a function of a nested type defined in the header file | of a templated class. | | Header file below | | //C++ STL classes have 12 type definitions, so that every class | // defines the following type names as nested types: | // | // value_type, pointer, reference, const_pointer, const_reference | //iterator, const_iterator, reverse_iterator, const_reverse_iterator | // allocator_type, size_type, diference_type | | typedef Etype reference; //list...::value_type to access | //whatever type this list holds | | | template class Etype | typename listEtype::reference | listEtype::const_iterator*() const I don't understand what that line is supposed to mean. It does not look C++ to me. -- Gaby
Re: [Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Actually it is modulo for all operations. But then do read the comment as far as the loop optimizer is concerned. It does not seem like it understands that it is modulo arithmetic. | and INT_MAX/-1 does not raise a trap. It that is the case, then it is one issue less. But that wasn't the purpose of this PR. The issue is far from resolved just because you assert that INT_MAX/-1 does not trap. -- Gaby
Re: [Bug c++/22154] New: [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| The following should compile according to this DR report (but it is only in
ready state so I am going to
| confirm it and then suspend it):
| class a {};
| typename ::a f();
|
| Also the following should not compile as a is not qualified then:
| class a {};
| typename a f();
If that is what the DR says, then the DR does not make any sense...
-- Gaby
Re: [Bug c++/21930] New: [4.1 regression] pretty printer confusion
reichelt at gcc dot gnu dot org [EMAIL PROTECTED] writes: | The error message reads: | | bug.cc: In function 'void foo(const AN) [with int N = 0]': | bug.cc:7: instantiated from here | bug.cc:3: error: no match for 'operator-' in '-((const A0)#'convert_expr' | not supported by dump_expr#expression error)' | | With gcc 4.0.0 I get the following message instead: | | bug.cc: In function 'void foo(const AN) [with int N = 0]': | bug.cc:7: instantiated from here | bug.cc:3: error: no match for 'operator-' in '-((const A0)(+ a))' | | I don't know why the plus sign appears before a, The plus sign is a bogosity in the tree representation, not correctly understaood by the pretty-printer, which cannot differentiate between conversion from reference to pointer, lvalue-rvalue conversion and real unary plus. They usually appear under the cover of CONVERT_EXPR. | but this suggests that | the regression is related to the recent introduction of UNARY_PLUS_EXPR: | http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02580.html Indeed. -- Gaby
Re: [Bug c++/21837] New: C++/C99 standard violation in for loop
ahelm at gmx dot net [EMAIL PROTECTED] writes:
| C++ standard quote:
|
| 3.3.2, paragraph 4:
| Names declared in the for-init-statement, and in the condition of if, while,
| for, and switch statements are local to the if, while, for, or switch
statement
| (including the controlled statement), and shall not be re-declared in a
| subsequent condition of that statement nor in the outermost block (or, for the
| if statement, any of the outermost blocks) of the controlled statement; see
6.4.
|
| However g++/gcc happily compiles:
|
| #include stdio.h
|
| int main(void)
| {
| for(int i=2;i4;i++)
| {
| int j = i;
| int i;
There is duplicate of this bug in the case of C++, see PR2288.
Re: [Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
schlie at comcast dot net [EMAIL PROTECTED] writes: | (In reply to comment #4) | Subject: Re: wrong-code with inlining and type-punned pointer | Because this is what the standard says is allowed. The standard also | says the comparisons and assignment between pointers without a case is | invalid code and should be diagnostic. Again this is what the standard | says for these things and GCC follows the C standard. | | Here's an interesting portion of the standard, which seems to direcly imply | that signed and unsigned lvalue references are presumed to validly alias; so | so this should place both in the same alias set, and potentially eliminate the | default warning when comparing pointers which differ only in signness, as Sorry, I don't see that implication. However, GCC already has a switch for tuning off such comparison. -- Gaby
Re: [Bug c/21664] New: array-of-empty-structure extension not properly defined
rguenth at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| For
|
| struct {} a[4]; int main() { return a[2] - a[1]; }
|
| the C frontend emits
|
| return 0 /[ex] 0;
|
| which will, at -O0 fault at runtime, at -O not due to RTL CSE.
|
| Is this even well-defined?
No, as you noted below.
| Should the C-frontend rather emit
|
| return 0;
|
| ? Of course this contradicts the C standard, but that does not
| allow empty structures anyway.
If you go back to the GCC mailing list (circa 2001, 2002), you'll see
heavy and hot debates about what the answer should be.
For that matter, the C++ standards allow empty structures but do not
allow return 0. I suppose the real question is what use do you have
for an array of empty structures.
-- Gaby
Re: Problem with use of anonymous types
Andrew Pinski [EMAIL PROTECTED] writes:
| On May 6, 2005, at 8:09 PM, Julian Cummings wrote:
|
| People are reporting trouble compiling blitz with gcc-4.0.0, and the
| compiler errors are resulting from the use of unnamed enums. A
| simple code
| illustrates the problem:
|
|struct nullType {};
|template typename T inline T operator+(const T a, nullType) {
| return a;
| }
|enum named { namedA = 1, namedB = 2 };
|enum { unnamedA = 2, unnamedB = 4 };
|struct bar {
| enum { namedC = namedA + namedB,
| unnamedC = unnamedA + unnamedB };
|};
|int main() {
|}
|
| The gcc compiler complains about trying to add unnamedA and unnamedB.
| Apparently it gets confused by the presence of the operator+
| overload for
| the empty struct nullType. I don't see why the compiler would think
| that
| the anonymous enumerators unnamedA or unnamedB would match with type
| nullType. Enumerators are supposed to default to integers when used in
| arithmetic operations such as operator+. Everything compiles fine
| when the
| operator+ overload is not present. The code compiles as is under
| gcc-3.4.
| What gives?
|
| This is a bug in your code. See PR 19404 and PR 20589.
Or this is a bug in the standard. There is an active core issue for
it. And I sent a request for further clarification and rationale.
(I've heard some rumours about manglings, but they don't make sense to me).
-- Gaby
Re: Problem with use of anonymous types
Julian Cummings [EMAIL PROTECTED] writes: | Hmmm... I just read through the bug reports you cited. Sounds to me like | this is still somewhat of an open issue, as to whether the compiler should | issue an error in these cases or simply silently discard any templated | function as a possible match for an operation involving an unnamed type. As You're right, the issue is still open. I think people should be careful in closing PRs related to that issue. I can see the reasoning behind the error but it does not make any sense to me. | was pointed out in the discussion, this is a *disastrous* change in the | standard behavior of gcc because it essentially makes it impossible to | safely use an unnamed enum type in an arithmetic operation. There is bound | to be some template function overload declared in some header file somewhere | that suddenly makes your code not work. I am shocked that there is no | compiler flag made available to restore the previous behavior, especially in | light of the fact that the disposition of this issue remains unresolved. I Please consider filling a PR and expliclty mention the fact that the issue is under discussion withing the C++ committee. | have checked several other C++ compilers now (Intel icc 8.1 and IBM xlC 7.0, | for instance) and they all accept my example. -- Gaby
Re: [Bug other/21350] configure reports only a warning when bison is not installed
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Are you building from the source tarball or from CVS? | If from the source tarball, you don't need bison which is why it is just a warning. | Otherwise this is a bug in the release process if bison is now required (and a regression). | What is the current error you are getting building GCC? The problem as I was able to reproduce on Peter's machine yesterday is the following: gcc-core from release repository does not seem to contain w pregenerated c-parse.c. At build time, the build machiery attempts to generate it from c-parse.in and was looking for bison which Peter did not have. For some reasons the build did not stop for clear and unambiguous reason, (and even sooner aat configure time). If we now require bison for gcc-core, then we should check that at configure time and abort. -- Gaby
Re: [Bug c++/16370] __attribute__((deprecated)) not useful on classes, and ugly function name listed for deperecation warnings on constructor
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 03:41 --- | We now get: | t.cc:36: warning: __comp_ctor is deprecated (declared at t.cc:18) | | note the extra space. The extra space is part of the name, if you ask me. -- Gaby
Re: Mainline build failure on i686-pc-linux-gnu
Andrew Pinski [EMAIL PROTECTED] writes: | And what version of the compiler were you starting with? | If it was 4.1.0 between the following patches: | 2005-04-08 Diego Novillo [EMAIL PROTECTED] | | Merge from tree-cleanup-branch: VRP, store CCP, store | copy-prop, incremental SSA updating of FUD chains and | newly exposed symbols. | | and | 2005-04-11 Diego Novillo [EMAIL PROTECTED] | | PR tree-optimization/20933 | * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move | | Then try with another compiler as 4.1.0 was broken during those two | dates really. You're right on all counts. Thanks! -- Gaby
Re: [Bug c++/12879] [3.4 Regression] double error message when using incomplete types in a struct
cmchugh at callixa dot com [EMAIL PROTECTED] writes:
| --- Additional Comments From cmchugh at callixa dot com 2005-04-13 00:56
---
| Broken in 3.4.3 on AIX 5.2;
|
| $ cat x.cpp
| struct Exception {
| static void raise () throw (Exception){ throw Exception(); }
| };
| $ g++ x.cpp
| x.cpp:2: error: invalid use of undefined type `struct Exception'
preferably
static void raise () throw (Exception){ throw Exception(); }
^
class 'Exception' is considered incomplete at this point, therefore
cannot be used as an exception type in an exception-specification.
We do not have carret diagnostic yet, but we can improve on the error
message :-)
-- Gaby
Mainline build failure on i686-pc-linux-gnu
Build of freshly updated mainline tree fails with: /home/gdr/build/4.1/./gcc/xgcc -B/home/gdr/build/4.1/./gcc/ -B/home/gdr/i686-pc- linux-gnu/bin/ -B/home/gdr/i686-pc-linux-gnu/lib/ -isystem /home/gdr/i686-pc-lin ux-gnu/include -isystem /home/gdr/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-de finition -isystem ./include -I. -I. -I/home/gdr/redhat/egcs/gcc -I/home/gdr/re dhat/egcs/gcc/. -I/home/gdr/redhat/egcs/gcc/../include -I/home/gdr/redhat/egcs/g cc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-e xceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-point er \ -c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o make[1]: *** [crtbegin.o] Aborted make[1]: Leaving directory `/home/gdr/build/4.1/gcc' make: *** [all-gcc] Error 2 Configuration options were: --enable-languages=c++ --disable-nls -- Gaby
Re: Mainline build failure on i686-pc-linux-gnu
Diego Novillo [EMAIL PROTECTED] writes: | On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: | | -c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ |-o crtbegin.o | make[1]: *** [crtbegin.o] Aborted | make[1]: Leaving directory `/home/gdr/build/4.1/gcc' | make: *** [all-gcc] Error 2 | | What's your top-of-ChangeLog? Works for me up to | | 2005-04-11 Diego Novillo [EMAIL PROTECTED] | | PR tree-optimization/20933 | * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move | [ ... ] I have 2005-04-11 Geoffrey Keating [EMAIL PROTECTED] * config/t-slibgcc-darwin: Don't put shared libraries in directories other than $(slibdir). * config/rs6000/darwin.h: Find -m64 libgcc under the name the OS uses for it. 2005-04-11 Diego Novillo [EMAIL PROTECTED] PR tree-optimization/20933 * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move logic to reject aliases between read-only and writable variables ... (may_alias_p): ... here. (get_tmt_for): Do not associate read-only tags to pointers whose pointed-to type is not read-only. * tree-ssa.c (verify_ssa): Check that memory stores have at least one V_MAY_DEF or V_MUST_DEF. Bootstrap fails at the same point as regular make. -- Gaby
Re: Mainline build failure on i686-pc-linux-gnu
Gabriel Dos Reis [EMAIL PROTECTED] writes: | Diego Novillo [EMAIL PROTECTED] writes: | | | On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: | | | | -c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ | |-o crtbegin.o | | make[1]: *** [crtbegin.o] Aborted | | make[1]: Leaving directory `/home/gdr/build/4.1/gcc' | | make: *** [all-gcc] Error 2 | | | | What's your top-of-ChangeLog? Works for me up to | | | | 2005-04-11 Diego Novillo [EMAIL PROTECTED] | | | | PR tree-optimization/20933 | | * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move | | [ ... ] | | I have | | 2005-04-11 Geoffrey Keating [EMAIL PROTECTED] | | * config/t-slibgcc-darwin: Don't put shared libraries in | directories other than $(slibdir). | * config/rs6000/darwin.h: Find -m64 libgcc under the name the | OS uses for it. This might be due to the bootstrapping compiler -- I was using a compiler built from yesterday tree to bootstrap Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/gdr/redhat/egcs/configure --prefix=/home/gdr --enable-languages=c++ --disable-nls Thread model: posix gcc version 4.1.0 20050411 (experimental) Blowing away that compiler and using the native compiler (3.3.1) of my system let me complete the build. Whatever problem there was yesterday, it seems to have been fixed. Thanks, -- Gaby
Re: [Bug c++/20734] New: rejects valid pointer to member
sstrasser at systemhaus-gruppe dot de [EMAIL PROTECTED] writes: | error: cannot convert 'int*' to 'int A::*' for argument '1' to 'void blah(int A::*)' This is clearly a bug in GCC. -- Gaby
Re: [Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
bangerth at dealii dot org [EMAIL PROTECTED] writes: | Well, I wanted to give an inuitive reasoning. I understood that; I just don't think they are conclusive :-) | On the other hand, how do you propose to make up a unique name if an | unnamed enum is used in two different translation units as a template | argument? They are different types, therefore have different internal names -- like unnamed namespaces. -- Gaby
Re: aren't specialized templates templates?
Tim Janik [EMAIL PROTECTED] writes:
| hi all.
|
| the code snippet below is extracted from a much more
| complicated piece of code. basically the problem is that
| g++ (3.3 and 3.4) demand different typedef syntax inside
| template bodies, depending on whether full or partial
| specialization is used.
|
| is this really the correct behaviour and standard conform?
Yes. An explicit specialization is not a template. Therefore line20
is in error.
| (to me it seems, line20 should still be considered part of
| a template and thus accept the typename)
|
| snip-
| templateclass C
| struct Base {
|typedef C* Iterator;
| };
|
| templateclass C, class D
| struct Derived : BaseD {
|typedef typename BaseD::Iterator Iterator;
| };
|
| #define BASE_ITER(BASE) typename BASE :: Iterator
|
| templateclass D
| struct Derivedchar, D : BaseD {
|typedef BASE_ITER (BaseD) Iterator; // line15
| };
|
| template
| struct Derivedchar, int : Baseint {
|typedef BASE_ITER (Baseint) Iterator; // line20
| };
|
| // test.cc:20: error: using `typename' outside of template
| snip-
|
|
| ---
| ciaoTJ
|
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Re: [Bug c++/19737] typename requirement error
gianni at mariani dot ws [EMAIL PROTECTED] writes:
| BTW - gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) accepts the
| code, would this be a regression ?
Previous versions of GCC did not quite understand the notion of
inject class name and would erroneously accept things like
struct A { };
A::A a;
-- Gaby
Re: [Bug java/19738] gcjh generates invalid class member floating-point initialisers
giovannibajo at libero dot it [EMAIL PROTECTED] writes:
[...]
| In fact, I personally use this to expose constants without linkage:
|
| struct A {
|enum { a = 45 };
| };
agree.
| but with floating point numbers you are out of luck.
Indeed.
-- Gaby
Re: [Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
joseph at codesourcery dot com [EMAIL PROTECTED] writes: | I've now sent it to c++std-compat (having checked that the C++ list of | characters also includes combining characters in more than one combining | class so the same issues can arise there at least in principle, whether or | not they can arise with realistic natural language identifiers). Thanks a lot! -- Gaby
Re: bug in /usr/include/c++/3.4/bits/fstream.tcc
Jacob Schmidt Madsen [EMAIL PROTECTED] writes:
| error:
| /usr/include/c++/3.4/bits/fstream.tcc: In member function `virtual
| typename std::basic_filebuf_CharT, _Traits::int_type
| std::basic_filebuf_CharT, _Traits::underflow()':
| /usr/include/c++/3.4/bits/fstream.tcc:277: error: expected
| unqualified-id before '(' token
| /usr/include/c++/3.4/bits/fstream.tcc: In member function `virtual
| std::streamsize std::basic_filebuf_CharT, _Traits::xsputn(const
| _CharT*, std::streamsize)':
| /usr/include/c++/3.4/bits/fstream.tcc:518: error: expected
| unqualified-id before '(' token
|
| solution found at:
| http://gcc.gnu.org/ml/gcc-bugs/2004-07/msg02128.html
|
| fix:
| change line 277 in /usr/include/c++/3.4/bits/fstream.tcc
| from: __ilen = std::min(__avail, __buflen);
| to: __ilen = min(__avail, __buflen);
I cannot see any reason why that would be a fix.
-- Gaby
Re: complex numbers
Andreas Klein [EMAIL PROTECTED] writes: | On Mon, 6 Dec 2004, Gabriel Dos Reis wrote: | | | As a matter of fact, the implementation of complex is criticized, | once in a while, because it does NOT use the grammar school rule you | present above. However, for float, double, long double it specializes | to __complex__ T which is what the compiler uses to implement complex | numbers in C99 and Fortran. So, the problem is a compiler problem not | libstdc++ problem. | | I have testet my program with a 2.95 and several 3.x versionsions of gcc. | The lastet version I have is 3.3.3. | All versions gave the same result. Yup. It is inside the compiler | What was the critice you mentioned above? I can not imagine a sitation in | which I would need the naive implementation. Oh, I got repeated complaints from users that the correct method of computation was slow -- look at the bugzilla archive. I believe there might alos be discussions on GCC main mailing list. The grammar school algorithms is needed for the primary template because it is the one that gets instantiated, for say, complexint. Notice that such datatypes are required by LIA-3 (in the last phase of development). We don't have overload on concepts so, for the moment that is what is used for anything other thand float, double, and long double. | But I think it can not be | good that if I get different result for complex and real arithmetic. If | the number are the same real numbers. | | | Did you look at the actual implementation? | | | As you mentinon it if have missed the specilization at the end of | std_complex.h. Sorry. I still think that we should have and other | implementation for complexfloating_point, but I cannot change the code | of __complex__ T in the complier. I don't think we need another implementation of complexfloating_point. What we need is to improve the compiler. Convince people that we have correctness, then speed. -- Gaby
Re: complex numbers
Andreas Klein [EMAIL PROTECTED] writes: | This look like a good deal. However for floting point computations I | prevere good results over fast results. You're in the minority (including me :-)). -- Gaby
Re: complex numbers
Andreas Klein [EMAIL PROTECTED] writes:
| Hello
|
| I have found a bug in the implementation of the complex library of
| g++ and the complex.h library of the gcc (c99 support).
|
| The simplest program that demonstrates the bug is:
|
|
|
| #includeiostream
| #includecomplex
|
| using namespace std;
|
| int main() {
| complexdouble a = 1.0/0.0; // + infinity
| complexdouble b = 1.0;
| complexdouble c = b/a; // should be 0 but is (NaN,NaN)
|
| cout a endl;
| cout b endl;
| cout c endl;
| }
|
|
|
| Since all values are real one should expect the result 0
| (the IEEE floating-point value for 1/infinity). More serious is that
| if a contains a large but representable value for which |a|^2 is not
| representable the implementation will yields bad results. For example
| let a be the largest representable number and b be a/2 then b/a should
| be 0.5 and not NaN.
|
| The bug comes from the naive implementation
|
| a + b Iac + bd bc - ad
| --- = --- + --- I
| c + d Ic^2+d^2 c^2+d^2
|
| We get unnecessary overflow errors if c^2+d^2 is too large.
|
As a matter of fact, the implementation of complex is criticized,
once in a while, because it does NOT use the grammar school rule you
present above. However, for float, double, long double it specializes
to __complex__ T which is what the compiler uses to implement complex
numbers in C99 and Fortran. So, the problem is a compiler problem not
libstdc++ problem.
[...]
| So my suggestion is to add template specialization for the
| operator/= for the types complexfloat complexdouble and
| complexlong double that use Smith formula. (For integer types I
| think we should stay with the old implementation.)
Did you look at the actual implementation?
-- Gaby
Re: [Bug c++/18514] [3.4/4.0 Regression] Alternate asm name ignored for redeclared builtin function imported into namespace std
austern at apple dot com [EMAIL PROTECTED] writes: | 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 I believe what happened there is that it was an attempt to implement the standard mandated semantics where names in xxx.h appears to be using-declarations for names in cxx -- except that the actual implementation gets everything wrong :-/ So the idea was that we get an artificial declaration in both :: and std::. If we actually write a decl in std::, that is it; same if we write it in ::. Except that the artificial declaration in :: should have been a using-declaration for the real artificial declaration in std::. And attributes and whatever should apply transparently to both -- because they have extern C language specification. That is what failed. -- Gaby
Re: [Bug libstdc++/18644] [3.3/3.4/4.0 regression] -Wsynth warning in complex
bangerth at ices dot utexas dot edu [EMAIL PROTECTED] writes: | The diagnostic is nonsensical. The fix is to fix the diagnostic, not | to paper over the problem. | | That's certainly the best solution. -Wsynth should just not trigger in | libstdc++ headers. yes, and even more in user codes where it does not make sense. Remember, we're currently compiling programs with ISO rules, and we have very very little provisions to compile programs with cfront rules (and you'd have to specify which version of cfront). -- Gaby
Re: [Bug fortran/18584] --std=f would be nice
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Oh, by the way how can they trademark a single letter. Ignorance? -- Gaby
Bad compile time complexity for large files ??? (fwd)
FYI. Joris's messages seem to have been blocked...
Please, CC: Joris when replying.
Joris --
It might help if you can provide information about the version of GCC
you're using. You might also want to try
http://gcc.gnu.org/bugzilla/
That way, your report will be recorded in the PR database.
---BeginMessage---
Salut Gabriel,
J'ai essaye plusieurs fois de poster le message ci-dessous
sur la liste gcc, mais c'est systematiquement refuse.
Peut-etre que tu peux le poster et me forwarder d'eventuelles reponses.
Je me suis desinscrit de la liste, car il y avait trop de messages.
A+, Joris
-- Forwarded message --
Date: Tue, 9 Nov 2004 12:00:47 +0100 (CET)
From: Joris van der Hoeven [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bad compile time complexity for large files ??? (fwd)
Hi,
I have suscribed to the gcc mailing list in order to send
the message below, but it keeps being rejected. Why?
Joris
-- Forwarded message --
Date: Tue, 9 Nov 2004 11:36:29 +0100 (CET)
From: Joris van der Hoeven [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bad compile time complexity for large files ???
Hi *,
I am using g++ for compiling automatically generated glue files
for another language (mathemagix). These glue files tend to become
quite big when I want to glue big C++ libraries. More precisely,
they contain a lot of small methods and routines, like
--
[...]
ext_inst
ext_mml_vector_rep::gen_timesassign (ext_inst arg_1, ext_inst arg_2) {
ext_type save_1 = ext_cur_1;
ext_cur_1 = x_1;
ext_inst ret = convertext_inst, mml_vectorext_inst_1
(convertmml_vectorext_inst_1, ext_inst (arg_1) *=
convertmml_vectorext_inst_1, ext_inst (arg_2));
ext_cur_1 = save_1;
return ret;
}
[...]
static mmx::generic
FUN_29 (mmx::generic g) {
return mmx::as_mmxdouble, TID (mmx::as_cppdouble, TID (g[1]) *=
mmx::as_cppdouble, TID (g[2]));
}
[...]
--
The number of classes is relatively small.
When the number of routines increases, I noticed a far more than
linear time complexity for the compilation time. This is very
disappointing for me, since it makes it nearly impossible to compile
glue files with more than a few hundred routines.
I suspect that this behaviour is due to a lack of optimization
in the way identifiers are stored by the compiler: does gcc use
a linked list instead of a hash table? Is there a compilation
option that I may have overlooked?
I would be very interested in having this important drawback being
removed; such an optimization will probably be interesting anyway,
since the performance already drops sharply for files with a few
thousand lines. If I can somehow help with improving this point,
then please let me know; I know nothing about the g++ source code,
but may learn the necessary if somebody guides me.
Best wishes, Joris
---
Joris van der Hoeven [EMAIL PROTECTED]
http://www.texmacs.org: GNU TeXmacs scientific text editor
http://www.math.u-psud.fr/~vdhoeven: personal homepage
---
---End Message---
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Texas AM University -- Department of Computer Science
301, Bright Building -- College Station, TX 77843-3112
Re: [Bug c++/16514] New: no warning of non-virtual dtor in subclass
naiman at math dot jct dot ac dot il:
Dear G++ Folk,
An astute student found the following example:
vv
class foo1 {
public:
virtual void f1 (void) {}
virtual ~foo1 (void);
};
class foo2 : public foo1 {
public:
~foo2 (void);
};
^^
We believe the compiler should at least warn that foo2
has a virtual function, and non-virtual dtor.
You're mistaken: foo2 has a virtual destructor.
The PR is invalid.
Re: [Bug libstdc++/9679] Strange behaviour of valarray::apply method
pcarlini at suse dot de [EMAIL PROTECTED] 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(valarraychar(y.apply(bar))[0]); -- Gaby
