--- 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 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 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 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: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 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-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-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 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-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-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 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 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 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 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: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-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-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 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-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-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 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-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-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 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 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: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-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-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 14:03
---
> The default pthread library in RedHat 8.0 does align stack properly, as I am
> able to trigger the bug. Testcase shows:
Uros, did you mean "does *not* align the stack properly"? If so,
--- Additional Comments From bangerth at dealii dot org 2004-12-15 14:10
---
I can't reproduce this. Can you post the exact output of gcc -v?
Thanks
Wolfgang
--
What|Removed |
--- 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-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-13 21:10
---
In case someone wondered about the mapping of the rank-3 array to the rank-2
array in my previous testcase: here is something even simpler:
==
subroutine choleskyzhp
--- Additional Comments From bangerth at dealii dot org 2004-12-13 20:55
---
I have something else (although of a quality that I don't trust myself)
in C in PR 12902.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990
--- Additional Comments From bangerth at dealii dot org 2004-12-13 20:54
---
I really have not much of an idea what I am doing here, but this
is a shorter testcase:
-
#include
typedef struct {
int i;
float f[3];
} a_t;
typedef struct {
float f
--- Additional Comments From bangerth at dealii dot org 2004-12-13 20:20
---
I should probably say that my installation is a little dusty already:
gcc version 3.4.3 20041015 (prerelease)
Maybe someone with a newer version can try to reproduce this.
W.
--
http://gcc.gnu.org
--- Additional Comments From bangerth at dealii dot org 2004-12-13 20:19
---
Richard,
I have added a small testcase in f77 to PR 14776. I'll try to come up
with something that can be used for mainline as well, but for now this
is at least some kind of testcase for you to work
--- Additional Comments From bangerth at dealii dot org 2004-12-13 20:18
---
Here is a small testcase that segfaults in a movapd instruction
when compiled with the 3.4 branch:
subroutine choleskyzhp (a)
integeri,j,k
complex*16 a
--- Additional Comments From bangerth at dealii dot org 2004-12-10 21:53
---
The fact that we don't issue any errors is a duplicate of PR 15684. However,
the code is fundamentally broken in that you cast a pointer to B into a
pointer to A and use it to do something with it.
--- Additional Comments From bangerth at dealii dot org 2004-12-10 18:13
---
Here's a small testcase:
--
const char *toHex( unsigned short u )
{
static char hexVal[5];
int i = 3;
while ( i >= 0 ) {
unsigned short hex = (u & 0x000f);
--- Additional Comments From bangerth at dealii dot org 2004-12-10 18:04
---
I can, however, confirm the segfault on top-of-mainline. No reduced
testcase, however.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-12-10 18:01
---
This used to work with my somewhat outdated version 20041015; it must
be a regression since then.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18928
--- Additional Comments From bangerth at dealii dot org 2004-12-08 16:29
---
Here's my shortest version:
---
extern "C" void abort ();
struct C {
__complex__ long double c;
};
int main() {
C x = {2+2i};
int n = 1;
C y = (n==1)
--- Additional Comments From bangerth at dealii dot org 2004-12-07 14:19
---
This is most likely the same as PR 18865.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793
--- Additional Comments From bangerth at dealii dot org 2004-12-07 02:58
---
It is in fact a 4.0 regression only. It compiles with gcc 3.4 as of
2004/10/15, but it fails with mainline from the same date.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18862
--- Additional Comments From bangerth at dealii dot org 2004-12-02 23:57
---
I would venture a guess that it was this patch:
2004-11-25 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/18445
* class.c (instantiate_type): Treat NON_DEPENDENT_EXPR
--
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18
tor() in
template
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
R
--- Additional Comments From bangerth at dealii dot org 2004-12-02 23:34
---
We can save one layer of objects:
-
struct S {
S();
S(const S&);
void operator=(const S&);
};
struct X {
int a, b, c, d, e;
S s;
};
void foobar ()
--- Additional Comments From bangerth at dealii dot org 2004-12-02 20:12
---
That's as short as I can get it for now:
--
#include
struct Record
{
unsigned int a, b, c, d, e;
std::string description;
};
template
void f
--
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.
--- Additional Comments From bangerth at dealii dot org 2004-12-02 19:58
---
Created an attachment (id=7663)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7663&action=view)
Preprocessed sources, not reduced
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793
ot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793
--- Additional Comments From bangerth at dealii dot org 2004-12-01 20:59
---
The two spinoffs are PR 18766 and PR 18767.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17619
verity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org,uros at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18767
th at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18766
--- Additional Comments From bangerth at dealii dot org 2004-12-01 20:49
---
In reply to comment #6:
> Please note, that we should return the result in fp reg, so final flds is
> needed in any case. I think, this code is optimal.
Almost, or at least I believe so. If we
--- Additional Comments From bangerth at dealii dot org 2004-11-30 22:48
---
Actually, this requires more thought. I quoted from the C++ standard, but
the bug is for C, and the problem lies here: the code is
-
size_t fsize3 (int n)
{
int i = 0;
char b[1][n+3
--- Additional Comments From bangerth at dealii dot org 2004-11-30 22:24
---
That's not a bug. The standard says this:
5.3.3 Sizeof[expr.sizeof]
1 The sizeof operator yields the number of bytes in the o
--- Additional Comments From bangerth at dealii dot org 2004-11-25 19:19
---
I am not an expert in ABI questions, but in my naive world constructors
are somewhat different than regular functions if they are declared
inline (and synthesized constructors always are):
- you can't
--- Additional Comments From bangerth at dealii dot org 2004-11-24 16:49
---
This has been discussed numerous times, and the main problem people had
in coming up with better diagnostics is that the operating system does
not communicate to a program why it is being killed. What happens
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18644
on: 4.0.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18644
--- Additional Comments From bangerth at dealii dot org 2004-11-22 15:05
---
Substitution of the return type fails, so in your example there really
is an empty set of overloads. That's what the compiler tells you.
I think the fact that we may print a message saying that the ove
--- Additional Comments From bangerth at dealii dot org 2004-11-16 22:45
---
*** Bug 18522 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-16 22:45
---
That's a duplicate of PR 18001. Sounds easier to fix than a good number
of other PRs, but nothing's happening apparently...
W.
*** This bug has been marked as a duplicate of 18001 ***
--
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:34 ---
*** Bug 18072 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:34 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:33 ---
Na, that was wrong, of course.
W.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
*** Bug 17403 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
*** Bug 16713 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
*** Bug 17772 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
*** Bug 18144 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:32 ---
*** Bug 15639 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:31 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:31 ---
*** Bug 15801 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:31 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:31 ---
*** Bug 18286 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:31 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:31 ---
*** Bug 17496 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:31 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:30 ---
*** Bug 17649 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:30 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:30 ---
*** Bug 18311 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:30 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:29 ---
*** Bug 18306 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:29 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:29 ---
*** Bug 18061 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:29 ---
Duplicate of PR 15552.
*** This bug has been marked as a duplicate of 15552 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:27 ---
These are all duplicates of PR 15552
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:27 ---
These are all duplicates of PR 15552
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:27 ---
These are all duplicates of PR 15552
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:27 ---
These are all duplicates of PR 15552
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:27 ---
These are all duplicates of PR 15552
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From bangerth at dealii dot org 2004-11-05 19:27 ---
These are all duplicates of PR 15552
--
What|Removed |Added
Status|RESOLVED
801 - 900 of 972 matches
Mail list logo
