--- Additional Comments From bangerth at dealii dot org 2005-06-03 22:27
---
In private mail, I got another testcase that is even weirder:
---
struct O {
template struct B {
void set (T, bool=true);
};
struct D : public B
--
What|Removed |Added
CC||giovannibajo at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzil
--- Additional Comments From bangerth at dealii dot org 2005-06-04 04:37
---
I'm sorry, but I have no idea what you mean by that. If you want to say
that O::B is instantiated by O::D, which is still inside O, yes, of
course that's the case. And I'm happy if the de
--- Additional Comments From bangerth at dealii dot org 2005-06-06 14:27
---
Sure it is a regression: gcc3.3.x compiles it just fine, and so does 3.2.x.
gcc2.95 ICES, and from 3.4 onward we have the present error.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-06-06 14:28
---
My last message refers to the code snippet in comment #4.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21903
--- Additional Comments From bangerth at dealii dot org 2005-06-07 23:28
---
I concur with the last post -- a dummy return at the end would solve
the problem and seems like an acceptable solution for a release
branch.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-06-16 20:00
---
The typedef you use is still a specialization of a template, so you
have to write
template <> intsample::keytype * intsample::keyptr = 0;
With this, it works.
W.
--
What|R
--- Additional Comments From bangerth at dealii dot org 2005-06-16 22:04
---
> b = (size_t)(p = &(int []){0, 1, 2}[1]);
What a perverse line of code -- I guess you got what you deserved :-)
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22098
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6880
--- Additional Comments From bangerth at dealii dot org 2003-07-24 14:38 ---
At least from a language viewpoint, there is certainly no bug in the generated
code: in one
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11857
--- Additional Comments From bangerth at dealii dot org 2003-08-09 15:45 ---
I don't think we should rate this as a regression. egcs was just even more wrong.
W.
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12097
--- Additional Comments From bangerth at dealii dot org 2003-08-28 18:24 ---
So is the fact that present mainline doesn't give anything due to the patch Zack
check
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12724
bangerth at dealii dot org changed:
What|Removed |Added
Target
--- Additional Comments From bangerth at dealii dot org 2003-12-16 08:02 ---
The program crashes because you attempt to use std::cout in the
initialization code of your global variable x_global which seems to run before
the initialization code of the global variable std::cout is run
--- Additional Comments From bangerth at dealii dot org 2004-01-28 14:13 ---
Confirmed, but fixed in 3.4.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From bangerth at dealii dot org 2004-03-03 16:11 ---
Confirmed, but already fixed in 3.4 and mainline due to the new parser:
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc
x.cc: In constructor `foo::foo()':
x.cc:2: error: expected `(' bef
--- Additional Comments From bangerth at dealii dot org 2004-12-16 16:50
---
This is a duplicate of PR 15114. It is fixed on mainline, but the audit
trail of that PR states that it is not going to be fixed for 3.4.x.
W.
*** This bug has been marked as a duplicate of 15114
--- Additional Comments From bangerth at dealii dot org 2004-12-16 16:50
---
*** Bug 19033 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-12-16 17:01
---
Created an attachment (id=7762)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7762&action=view)
Slightly smaller testcase
Attached is a slightly smaller testcase (down to 183,000 lines or so).
--- Additional Comments From bangerth at dealii dot org 2004-12-16 21:01
---
That's because it doesn't have to evaluate the #elif condition any more,
since it has already taken the #ifdef branch. If you change the code to
#ifdef BAR
return 1;
#el
--- Additional Comments From bangerth at dealii dot org 2004-12-17 00:12
---
*** Bug 19047 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-12-17 00:12
---
This is a duplicate of one of the weirdest bugs we have ever had, PR 17344.
W.
*** This bug has been marked as a duplicate of 17344 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-12-17 16:34
---
Nathan, if this isn't a regression but a patch has been applied to the
3.4 branch, then you should also apply it to mainline. Otherwise you have
just created a regression (3.4.4 will work as expected
--- Additional Comments From bangerth at dealii dot org 2004-12-14 03:56
---
My testcase was actually for x86 linux, but since you fixed it in
that other PR today, I assume that the same bug triggered but PRs,
so closing this one should be ok.
W.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From bangerth at dealii dot org 2004-12-14 14:09
---
In response to comment #30: it is libpthread's responsibility to align the
stack of subthreads properly. It doesn't do that, however, but I believe
that we have another PR for that (this is somethi
--- Additional Comments From bangerth at dealii dot org 2004-12-15 14:13
---
Uros, do you have a testcase?
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From bangerth at dealii dot org 2004-12-15 15:44
---
Try using -ffloat-store to get what you expect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19011
--- Additional Comments From bangerth at dealii dot org 2004-12-16 16:40
---
I can confirm this. We get a million error messages before the place where
we crash, though. And the testcase has some 247,000 lines...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
--- Additional Comments From bangerth at dealii dot org 2004-12-19 20:01
---
Why not the minimal testcase:
-
template struct X;
template struct X<_Tp _Cp::*> {};
typedef int F();
struct S { F f; };
typedef F S::*PMF;
--- Additional Comments From bangerth at dealii dot org 2004-12-19 22:19
---
I should have been more clear: the problem is with matching a pointer-
to-member-function with a pointer-to-member template.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-12-19 22:30
---
The reason why this is a bug has never been stated in this PR: addresses
of member functions/variables can only be taken if they are fully qualified
by their class name.
W.
--
http://gcc.gnu.org
--- Additional Comments From bangerth at dealii dot org 2004-12-20 15:13
---
An attribute could work. I doubt that a general flag would be useful,
since one in general doesn't know which functions are thread entry
points, so the compiler would have to emit such stack alignment
--- Additional Comments From bangerth at dealii dot org 2004-12-20 15:15
---
This last testcase indeed still shows the problem. It doesn't compile
with gcc, but does with icc.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076
--- Additional Comments From bangerth at dealii dot org 2004-12-20 15:34
---
Confirmed. It works in 2.95 and mainline, but nothing in between (I
tested 3.2.3, 3.3.4, 3.4.3). It is thus a regression, although I
believe not a very serious one given that the code is in fact invalid
and
--- Additional Comments From bangerth at dealii dot org 2004-12-20 17:08
---
A patch (with following long discussion) has been proposed here:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01495.html
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617
--- Additional Comments From bangerth at dealii dot org 2004-12-20 17:14
---
The question raised in several of the messages in that discussion
is whether an enumeration of equality checks is converted into a
range check if the tested values are consecutive.
Here is the answer
--- Additional Comments From bangerth at dealii dot org 2004-12-20 20:43
---
Indeed. It seems as if I am not the only one who wasn't aware of the
restriction that dependent function calls can only be to functions with
external linkage.
This should be low priority, since we
--- Additional Comments From bangerth at dealii dot org 2004-12-20 21:30
---
Actually, we can make this a rejects-valid like so:
--
namespace NS1 {
struct X {};
void foo(X);
}
namespace NS2 {
static void foo(NS1::X);
template
void bar
--- Additional Comments From bangerth at dealii dot org 2004-12-21 02:40
---
This works for me, too, with a snapshot from 2004-12-14, or at least it
doesn't abort and returns a return code of 1. What do you see, and what
flags exactly do you use? I tried with
-march=pentium4
--- Additional Comments From bangerth at dealii dot org 2004-12-21 06:51
---
Confirmed. This is in line 697 of version 1.20 of that file. This
should definitely be resolved before 4.0 goes out.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-12-21 17:36
---
gcc is correct: the result of getSomething is a temporary. Temporaries can
only be bound to const references, not to non-const ones. Thus, the
constructor
UsePointer(Pointer &p
--- Additional Comments From bangerth at dealii dot org 2004-12-23 17:14
---
Joseph's comment points to the exact right place. The result should be zero.
Confirmed with gcc 3.3 and mainline.
W.
--
What|Removed |
--- Additional Comments From bangerth at dealii dot org 2004-12-23 23:05
---
A special case of what is covered in this PR is PR 19138.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
--- Additional Comments From bangerth at dealii dot org 2004-12-23 23:06
---
This PR only covers a special case of the other PR, so I would be tempted
to keep both open and if the other one is fixed checked whether this also
covers the special case discussed here. I'm not sure wh
--- Additional Comments From bangerth at dealii dot org 2004-12-23 23:19
---
I'll be happy to defer to your superior technical knowledge :-)
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19138
--- Additional Comments From bangerth at dealii dot org 2005-01-03 05:24
---
Confirmed. This is a regression over 3.4.x.
My mainline snapshot if from 20041214, so the problem predates that date.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-01-03 05:30
---
The minimal testcase is this:
extern double log1p (double __x);
double test () {
return log1p(1.0);
}
g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -ff
--- Additional Comments From bangerth at dealii dot org 2005-01-03 14:34
---
Uros, would you mind adding the testcase as well? I know it's small, but
who knows what it's good for -- we got this case wrong once already, let's
make sure we don't again.
Thanks
W
--- Additional Comments From bangerth at dealii dot org 2005-01-06 14:40
---
Some more discussion:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00176.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19252
--- Additional Comments From bangerth at dealii dot org 2005-01-06 14:46
---
Giving explicit template arguments for template operators works
the same way: write
x.operator<< (abc)
instead of
x << abc
As for the evolution of C++: it isn't C++ but rather gcc
--- Additional Comments From bangerth at dealii dot org 2005-01-06 17:41
---
Nah, that may be your Eurocentric viewpoint. Over here in Texas one
thinks differently :-))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19288
--- Additional Comments From bangerth at dealii dot org 2005-01-07 20:58
---
This one is simpler:
-
template void foo (R (T::*x) ());
template void foo (R (T::*x) (C));
template struct I {
int o ();
int o () const;
};
template void bar
--- Additional Comments From bangerth at dealii dot org 2005-01-08 20:03
---
Analysis is here and in the follow-up:
http://gcc.gnu.org/ml/gcc/2005-01/msg00460.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
--- Additional Comments From bangerth at dealii dot org 2005-01-08 20:13
---
The fact that it worked for the integer case is by chance, since gcc
seems to have been able to replace all references to that variable
by its value, but it wasn't for the floating point case. That is
--- Additional Comments From bangerth at dealii dot org 2005-01-09 22:48
---
I also wonder what the semantics are that you are expecting? I mean,
you try to allocate an array that is so large that you can't address
the individual bytes using a size_t, in other words one th
--- Additional Comments From bangerth at dealii dot org 2005-01-10 04:21
---
You are trying to overload operator<<(std::ostream, float). That
can't work, since there is already an overload for that.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19288
--- Additional Comments From bangerth at dealii dot org 2005-01-18 02:36
---
I'm surprised this is something that hasn't been found yet by one of our
users. I'd vote to up its importance, it's a rejects-valid of the nasty
kind since it's going to be almost imp
--
What|Removed |Added
Summary|MMX load intrinsic produces |MMX load intrinsic produces
|SSE superflus instructions |SSE superfluous instructions
--- Additional Comments From bangerth at dealii dot org 2005-01-20 20:46
---
To be completely clear, the compiler generated default constructor is
ptr() : a(0) {}
not
ptr() {}
Thus, it _does_ initialize 'a'.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19544
--- Additional Comments From bangerth at dealii dot org 2005-01-22 18:37
---
Why? The function you want is inline. I would rather claim that the
instantiation of the function in the general template is wrong,
although arguably it doesn't matter since it is marked weak.
You
--- Additional Comments From bangerth at dealii dot org 2005-01-26 04:12
---
This is certainly undefined code: you are dereferencing the Null pointer.
It's a different matter of QoI whether we want to support this anyway.
It's basically a different way to say offsetof,
--- Additional Comments From bangerth at dealii dot org 2005-01-26 04:16
---
The declaration of a specialization is not a definition, unless it has
an explicit initializer call. The way you want to write this is
as follows:
template <> A B::a = A();
The standard specificall
--- Additional Comments From bangerth at dealii dot org 2005-01-26 04:25
---
You are accessing something here
var[1].adresse()
that definitely is not an A, but sitting somewhere between other
objects. That's definitely not allowed.
W.
--
What|Re
--- Additional Comments From bangerth at dealii dot org 2005-01-28 01:08
---
Confirmed, although I consider this to be a rather minor point since
the code is actually run only once. Here's a small test:
struct A {
A();
~A() {}
};
voi
--- Additional Comments From bangerth at dealii dot org 2005-01-28 17:01
---
atexit only takes a pointer to a function to be run on exit of the
program. The fact that this is an empty function is unbeknownst to
it, and probably the code in the middle-end that has to deal with
that. I
--- Additional Comments From bangerth at dealii dot org 2005-01-28 19:11
---
Why do you think the front-end doesn't know that the destructor is empty?
It sees its definition, and it knows about potential destructors of
member objects and base classes, so it should have al
My code segfaults basically immediately when using -ftree-vectorize.
Preprocessed sources are appended. To reproduce, do this:
spec/src> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -march=pentium4 -O
-ftree-vectorize x.ii -o x
spec/src> ./x
Segmentation fault
This is with mainline CVS a
--- Additional Comments From bangerth at dealii dot org 2005-01-31 00:41
---
Created an attachment (id=8109)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8109&action=view)
Preprocessed sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19716
--
What|Removed |Added
GCC target triplet||i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19716
--- Additional Comments From bangerth at dealii dot org 2005-01-31 00:56
---
Here is a self-contained testcase:
--
struct A {
double values[3];
A () {
for (unsigned int i=0; i!=3; ++i)
values[i] = 0;
}
};
double f() {
A
--- Additional Comments From bangerth at dealii dot org 2005-01-31 01:01
---
BTW, I have glibc 2.3.3, which in the other PR is specifically listed as
a version for which the bug doesn't happen. So this is not a duplicate.
The system as a whole is suse 9.2, right out of the box.
--- Additional Comments From bangerth at dealii dot org 2005-01-31 03:11
---
Nope, -fno-ivopts doesn't make any difference.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19716
--- Additional Comments From bangerth at dealii dot org 2005-01-31 14:02
---
gcc 3.2.x was definitely not stable on opteron. As far as I remember,
opteron support was developed by SuSE on the hammer branch and by
redhat on top of their 3.2.x based compiler. I believe that both folded
--- Additional Comments From bangerth at dealii dot org 2005-01-31 19:30
---
In general, you have to make sure that you have the required versions
of other packages. As for helping you to sort out hardware problems --
please look elsewhere on the web, this forum here is concerned with
--- Additional Comments From bangerth at dealii dot org 2005-02-01 13:57
---
I'm not a native speaker, but to me, too, this error message sounds very
awkward. Even if the sentence should be grammatically correct, there is
no reason we shouldn't choose a less awkward wording
--- Additional Comments From bangerth at dealii dot org 2005-02-01 14:27
---
This is in fact true. There is a mismatch between error messages for
template function arguments and non-templates:
void foo1();
template void foo2();
template
--- Additional Comments From bangerth at dealii dot org 2005-02-01 17:30
---
Except that, of course, in the present case the overload set contains
only a single function (foo2 isn't overloaded, and we have specified
all template arguments). Which should make it even easier to h
--- Additional Comments From bangerth at dealii dot org 2005-02-01 17:33
---
> Andrew is a native speaker. Really, he is. ;-)
Ah, c'mon. He has improved recently. Me sure he have really.
W.
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-02-03 16:29
---
Convincing evidence has been provided. I'll close the PR.
W.
--
What|Removed |
--- Additional Comments From bangerth at dealii dot org 2005-02-07 21:53
---
Confirmed. We should get a warning for this code, but don't:
--
struct S
{
int i, j;
S() : i(j), j(1) {}
};
S s;
---
W.
--
--- Additional Comments From bangerth at dealii dot org 2005-02-08 19:58
---
I can confirm this:
tmp/xxx> c++ x.cc
tmp/xxx> ./a.out
tmp/xxx> c++ x.cc -O2 -finline-functions -finline-limit=604
tmp/xxx> ./a.out
Segmentation fault
tmp/xxx> c++ -v
Using built-in
--- Additional Comments From bangerth at dealii dot org 2005-02-08 20:13
---
This is somewhat shorter, though maybe not much:
#include
#include
struct ltstr {
bool operator()(const char* s1, const char* s2) const
{ return strcmp(s1, s2) <
--- Additional Comments From bangerth at dealii dot org 2005-02-09 19:24
---
There's also other stuff lurking in assembler files, such as a lot of
notes for labels. These aren't code, and I've seen cases where newer
compilers output more labels than older ones
--- Additional Comments From bangerth at dealii dot org 2005-02-11 17:44
---
Quite naively, I would say that this could even be ok, just that there will
never be a member variable the address of which one could initialize this
pointer-to-member with. Do you have chapter and verse
--- Additional Comments From bangerth at dealii dot org 2005-02-11 17:50
---
Volker, you seem to be on a quest to make gcc accept without crashing even
the most obnoxious wrong code snippets without ICEing. How do you generate
all these snippets?
(As a sidenote, even if they are
--- Additional Comments From bangerth at dealii dot org 2004-10-11 12:54 ---
I concur with Giovanni: this is a case very much like the format
checking for printf and attribute sentinel. If you simply remove
the attribute statement, then the generated code is exactly the
same in all
--- Additional Comments From bangerth at dealii dot org 2004-10-12 16:07 ---
If this is put under a flag of its own, it may actually be useful. I
see no reason why we should dismiss it that quickly.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-10-12 16:14 ---
Yes, me too. What a funny message :-)
BTW, this is how the bug evolved over time:
g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc
x.cc: In function `int main()':
x.cc:9: warning: 'o
--- Additional Comments From bangerth at dealii dot org 2004-10-13 01:43 ---
This seems to have been broken by a patch for which Zack assumed
responsibility here:
http://gcc.gnu.org/ml/gcc/2004-10/msg00464.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17964
--- Additional Comments From bangerth at dealii dot org 2004-10-13 03:07 ---
Can you post the complete command line? I can't reproduce with Giovanni's
options as well as -O2 with a snapshot from 20040930.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17965
--- Additional Comments From bangerth at dealii dot org 2004-10-13 12:50 ---
I'm not sure this is a bug: the standard quite unmistakably says that
default arguments aren't evaluated unless used. Now, if I try to
use the default argument in your testcas
--- Additional Comments From bangerth at dealii dot org 2004-10-13 13:29 ---
I still can't reproduce with a snapshot from an hour ago. This is
my command line:
/home/bangerth/bin/gcc-4.0-pre/bin/c++ -mtune=k8 -c x.cc -O2
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17965
--- Additional Comments From bangerth at dealii dot org 2004-10-13 21:10 ---
The workaround is to write
return k.template is_a_xfer();
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17981
--
What|Removed |Added
Summary|segfault in c++ code|unaligned xmm movaps on the
|(unaligned movaps on the|stack
|stack)
--- Additional Comments From bangerth at dealii dot org 2004-10-14 12:58 ---
This has been reported many times. In essence, you cannot use a
temporary as a stringstream object as in
ostringstream() << something;
The standard doesn't allow this.
W.
--
--- Additional Comments From bangerth at dealii dot org 2004-10-14 13:01 ---
You can't do that -- your code violates aliasing rules.
W.
--
What|Removed |
cc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org,jsm at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18001
--- Additional Comments From bangerth at dealii dot org 2004-10-14 16:35 ---
Thinking about it, finding a testcase wasn't all that hard:
--
int main ()
{
&1;
}
--
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18001
--- Additional Comments From bangerth at dealii dot org 2004-10-14 17:33 ---
Andrew, I'm getting angry when you selfishly close PRs that other people
think are useful to be kept open. The submitter of this PR has shown that
the cases you claim exist are not frequent, and that
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:50 ---
This is a duplicate of PR 4882.
W.
*** This bug has been marked as a duplicate of 4882 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-10-15 14:50 ---
*** Bug 18007 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
901 - 1000 of 1203 matches
Mail list logo
