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
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
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:
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 =
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
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
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;
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
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
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
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
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.
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
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
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;
|
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 }
|
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)
| {
|
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
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*
[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
[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
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
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
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
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
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;
|
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
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
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
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
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
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
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.
--
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
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
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,
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
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
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
|
|
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,
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
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
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
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
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.
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
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
|
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
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
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
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),
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
|
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.
|
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
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
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).
|
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,
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,
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
|
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
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
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
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
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
-
|
|
| ---
| ciaoTJ
|
--
Gabriel Dos Reis
[EMAIL PROTECTED]
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
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
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
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
|
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
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
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
|
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
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
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Oh, by the way how can they trademark a single letter.
Ignorance?
-- Gaby
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
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);
};
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
78 matches
Mail list logo
