"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 he
"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 (
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| For this simplified code:
|
| template
| char* f1() { if (c == 0) return 0; else return new char[c]; }
| char* f2() { return f1<0>(); }
|
| the C++ frontend issues an unconditional warning. When compiling with no
| options, I get
|
| foo.cc:
"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
"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
"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:
| 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
"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;
| >
"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
"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;
"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.
T
"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 compiler-
"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
|
| 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
"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
<[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:
| > |
| >
<[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) constr
"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 th
"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 cla
"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
"pault at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
[...]
| URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110310
| Log:
| 2005-01-28 Paul Thomas <[EMAIL PROTECTED]>
|
| PR fortran/25964
| * resolve.c (resolve_function): Exclude statement functions from
|
"rcbilson at plg dot uwaterloo dot ca" <[EMAIL PROTECTED]> writes:
| Consider:
|
| #include
| #include
|
| class xxx {
| friend int main();
| void *q;
| public:
| void *r;
| };
|
| int main() {
| std::cout << "offset of xxx::q is " << offsetof( xxx, q ) << "\n";
| std::c
"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 t
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| std::cout << static_cast(t) << std::endl;
| }
|
| If "static_cast" would work, the compiler should warn.
given call-by-value, you must be joking.
-- Gaby
"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
"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 applica
"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
| calle
"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 e
"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.
"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
|
"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_linkag
"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
| >
| >(reinterp
"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 th
"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
"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
"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)
"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
"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
"algorithmus at gmail dot com" <[EMAIL PROTECTED]> writes:
| ---new.cpp
| #include
|
| #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
that works all the time.
PR invali
"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
"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 qual
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The error message reads:
|
| bug.cc: In function 'void foo(const A&) [with int N = 0]':
| bug.cc:7: instantiated from here
| bug.cc:3: error: no match for 'operator-' in '-((const A<0>&)#'convert_expr'
| not supported by dump
"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 belo
"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 m
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:
| >
| > stru
"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
"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
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, incre
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]: ***
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
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
"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 u
--
|
|
| ---
| ciaoTJ
|
--
Gabriel Dos Reis
[EMAIL PROTECTED]
"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
"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
str
"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 the
"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: expecte
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:
| On Mon, 6 Dec 2004, Gabriel Dos Reis wrote:
|
| >
| > As a matter of fact, the implementation of is criticized,
| > once in a while, because it does NOT use the grammar school rule you
| > present above. However, for float, doub
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:
|
|
|
| #include
| #include
"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 c
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Oh, by the way how can they trademark a single letter.
Ignorance?
-- Gaby
]>
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.
The
78 matches
Mail list logo
