--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18
07:05 ---
Subject: Bug 19216
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-18 07:05:28
Modified files:
gcc/testsuite : ChangeLog
Log message:
PR l
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:18 ---
This is fixed by Paul T. Richard's namelist patch, but there still is a testcase
(gfortran.dg/pr19216.f) to commit on 4.0 branch.
--
What|Removed |Added
---
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18
07:34 ---
Subject: Bug 20950
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-18 07:34:33
Modified files:
gcc/testsuite : ChangeLog
libgfortran: C
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:39 ---
This is indeed legal, and fixed by Thomas's recent namelist patch. Will have to
be committed on 4.0 once it's open again.
--
What|Removed |Added
---
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:40 ---
Patch commited to mainline. Waiting for 4.0 to reopen.
--
What|Removed |Added
Ke
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:44 ---
This is fixed by Paul's recent namelist patch, applied on mainline. Will be
fixed on 4.0 once it's reopened.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:46 ---
This one is fixed by the recent namelist patch, will be fixed on 4.0 when it's
reopened.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:50 ---
Fixed by the recent namelist patch. Will be fixed on 4.0 once it's reopened.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:52 ---
The uppercase problem is fixed by Paul's recent patch on mainline (will be fixed
on 4.0 once it's reopened).
Leave this bug open until someone can confirm if leading space is required for
namelist output
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:54 ---
This is an extension indeed, and is incorporated in mainline by Paul's recent
namelist patch. Will be included in 4.0 when it reopens.
--
What|Removed |Added
--
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:59 ---
Confirm this bug. This is g77-only. Changed component to libf2c.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
08:02 ---
Fixed by Paul's recent namelist patch. Will be fixed on 4.0 when it's reopened.
--
What|Removed |Added
-
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
08:05 ---
This is a duplicate of 18122 (which has just been fixed).
*** This bug has been marked as a duplicate of 18122 ***
--
What|Removed |Added
-
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
08:05 ---
*** Bug 18591 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
08:06 ---
Fixed by Paul's recent namelist patch. Will be fixed on 4.0 when it's reopened.
--
What|Removed |Added
-
--- Additional Comments From falk at debian dot org 2005-04-18 08:10
---
(In reply to comment #6)
> Hi. It can well be a libstdc++ problem, and indeed I can imagine ways to avoid
> signed integers in the code. However, I'm not sure that someone will actually
> do the work, given the soon
--- Additional Comments From adah at netstd dot com 2005-04-18 09:06
---
Function calls, memory barriers, (and "lock" operations?) are all overheads. I
would like that
* GCC provide extensions so that GCC users can use memory barriers and
threading calls in a platform-independent way,
--- Additional Comments From giovannibajo at libero dot it 2005-04-18
09:08 ---
A segfault in GCC is always a bug, even if the code is wrong. Would you please
open a new bugreport about it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-18
09:23 ---
I messed up the quotation too. :-( It should read:
#undef CPP_SPEC
#define CPP_SPEC" \
%(cpp_cpu) \
%(cpp_arch) \
%{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic_} \
%{posix:-D_POSIX_SOURCE} \
"
--
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-04-18
09:33 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01959.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-18 11:16
---
Appeared on hppa64-hpux between 2005-04-09 01:34 UTC and 2005-04-09 01:38 UTC.
I.e., caused by tree-cleanup-branch merge.
--
What|Removed |Added
-
template< typename _Key,typename _Val,typename _KeyOfValue,typename
_Compare,typename _Alloc> class _Rb_tree;
template< typename _Key,typename _Compare,typename _Alloc >class multiset{
multiset(_Compare const& __comp,
typename _Rb_tree<_Key,_Key,_Key ,_Compare,_Alloc > ::allocator_type const&
__a=_
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-18 11:20
---
Appeared on x86_64-linux between 2005-04-12 21:33 UTC and 2005-04-12 21:37 UTC.
I.e., caused by
2005-04-12 Steven Bosscher <[EMAIL PROTECTED]>
Stuart Hastings <[EMAIL PROTECTED]>
Ja
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
12:03 ---
Using the testcase from comment #4, it seems clear that there is no check on
whether the slice selected has negative width...
atmp.2.dim[0].stride = 1;
atmp.2.dim[0].lbound = 0;
atmp.2.dim[0].
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-18 12:04 ---
here's another, simpler, testcase:
template< typename T1,typename T2> class A; //it works with only 1 parameter
class B{
template
void hoh(typename A::depname a=A::depname());
};
I'd appreciate a s
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-18 12:08 ---
fixed
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From matz at suse dot de 2005-04-18 12:49 ---
So, any progress on this whole issue? I don't see either the pragmas in the
C++ headers, nor HJs changes to the c++ frontend (despite testcase) in CVS.
Just for the record, I see these problems (linkproblem with te
--- Additional Comments From matz at suse dot de 2005-04-18 12:50 ---
Oh, and just annotating the testcase with the visibility push/pop #pragma
is not enough, probably because of the problem in the c++ frontend, HJ noted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
13:12 ---
I think I found a patch for this one. See
http://gcc.gnu.org/ml/fortran/2005-04/msg00507.html
--
What|Removed |Added
---
Hello,
there must be a serious problem in
GNU C++ version 4.0.0 20050410 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 3.3.4 (pre 3.3.5 20040809) (SuSE Linux 9.2).
The same happens with GNU C++ version 4.0.0 20050410 when built with itself.
On a
--- Additional Comments From leslie dot barnes at amd dot com 2005-04-18
13:37 ---
(In reply to comment #4)
> A segfault in GCC is always a bug, even if the code is wrong. Would you
> please
> open a new bugreport about it?
Sorry, I wasn't clear. The binary seg faults, not the compi
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:14
---
Hi Michael and thanks for asking: really, I'm lost in this tangle of front-end,
back-end and library issues. When I'm back from Oxford really want to move the
issue forward, somehow, asking all the knowledgeable pe
Consider:
int
foo (int *p)
{
int a = *p;
int b = p != 0;
*p = b;
if (b)
return a;
else
return 0;
}
Here is what I get with -O2 -fno-tree-dominator-opts
foo (p)
{
int b;
int a;
int D.1235;
:
a_3 = *p_2;
p_7 = p_2;
b_4 = p_7 != 0B;
*p_7 = b_4;
p_10 = p_7;
if
--- Additional Comments From matz at suse dot de 2005-04-18 14:22 ---
This patch fixes the regressions in khtml for us.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:23
---
> This is news to me. Does this mean that vector is not going to be
> special-
> cased any more? That seems like a very bad idea to me, since programs will
> suddenly take 8 times as much memory (or even more). Wh
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12884
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18879
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19467
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-18
14:42 ---
Michael, have you run the GCC testsuite with your patch? If not, please run on
several platforms and confirm that you get no regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
ow what's the
cause for this, the line reported, 17279, definitly is valid.
attaching source.
ICE with: gcc version 4.0.0 20050418 (prerelease)
works with: gcc-Version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
--
Summary: ICE in do_nonmember_using_decl
Product: gcc
--- Additional Comments From matz at suse dot de 2005-04-18 14:51 ---
>From
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01508.html
where I submitted the patch:
the problem in khtml. I've bootstrapped it with gcc 4.0 on
i686,x86_64,ppc,ppc64,ia64,s390 (s390x was breaking for d
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-18 14:51 ---
Created an attachment (id=8676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8676&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
--- Additional Comments From mckinlay at redhat dot com 2005-04-18 14:55
---
I don't think a gij test failure is expected. Array_3 is known to fail when
native compiled, however.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
Around tree-vrp.c:420, we have
t = fold (build2 (LT_EXPR, TREE_TYPE (val1), val1, val2));
if (t == boolean_true_node)
return -1;
Since VAL1 is known to be of a pointer type, the result of fold will never
be equal to boolean_true_node, which is of the boolean type.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18
15:18 ---
Subject: Bug 20922
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-18 15:18:22
Modified files:
gcc: ChangeLog fold-const.c
gcc/t
--- Additional Comments From phython at gcc dot gnu dot org 2005-04-18
15:20 ---
Fixed in the last commit.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 19986 depends on bug 20922, which changed state.
Bug 20922 Summary: missed always false conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
What|Old Value |New Value
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
--
What|Removed |Added
CC||hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:20 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18
17:21 ---
Subject: Bug 21049
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-18 17:20:57
Modified files:
gcc: ChangeLog
Log message:
Add
--- Additional Comments From dpatel at apple dot com 2005-04-18 17:23
---
Subject: Re: [4.1 regression] ICE with -ftree-vectorize
This is because invert_truthvalue() does not return
valid GIMPLE expr. I've a patch, once it passes
usual test cycle, I'll post patch.
-
Devang
--
ht
See this testcase:
-
struct Ball {
static const double diameter = 20;
void setPosition(double ,double );
double vect_Pos;
};
void move (double, double);
void Ball::setPosition(double xval,double yval) {
vect_Pos=xval;
move(xval-(diameter/2),
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:32 ---
Yes this is invalid C++ (and is rejected by -pedantic) but we somehow declared
this as an extension see
PR 11393 which is still open and other threads within a past year.
*** This bug has been marked as a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:32 ---
*** Bug 21089 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:38 ---
This is a documented deprecated feature:
http://gcc.gnu.org/onlinedocs/gcc/Deprecated-Features.html#Deprecated-Features
G++ allows static data members of const floating-point type to be declared with
an ini
Consider:
int g, h;
int
foo (int a)
{
int *p;
if (a)
p = &g;
else
p = &h;
if (p != 0)
return 1;
else
return 0;
}
With -O2 -fno-dominator-opts, VRP does not optimize away the "if" statement.
This is because VRP does not run the propagator when it does not insert
any A
--- Additional Comments From matz at suse dot de 2005-04-18 17:40 ---
Indeed. Okay, but then this really is an optimization regression compared
to gcc 3.3.x which compiled this just fine. As it's only rejected with
-pedantic (and I think it's a sensible extension), shouldn't we make s
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:47 ---
(In reply to comment #2)
> Indeed. Okay, but then this really is an optimization regression compared
> to gcc 3.3.x which compiled this just fine. As it's only rejected with
> -pedantic (and I think it's
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:50 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:53 ---
It has nothing to do with members of classes either, see the following code:
static const double a = 1.0;
static const double b = a+1.0;
double c()
{
return b;
}
We now longer inline 2.0 into c.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
17:56 ---
Simple code which shows we now have a missed optimization:
static const double a = 1.0;
static const double b = a+1.0;
double c()
{
return b;
}
See PR 21089.
--
What|Removed
--- Additional Comments From matz at suse dot de 2005-04-18 17:59 ---
With -O0 we also don't inline 'a'. I thought in the past this already
was done in the frontend, so the -O option didn't matter? If yes, this
has changed (if not, well, I'm wrong ;-) ).
--
http://gcc.gnu.org/
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-18
17:59 ---
The patch in Comment #13 is OK for 4.0.0. It's a pessimization, but it's rather
more obviously correct. Please apply forthwith. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:04 ---
(In reply to comment #6)
> With -O0 we also don't inline 'a'. I thought in the past this already
> was done in the frontend, so the -O option didn't matter? If yes, this
> has changed (if not, well, I'
When compiling for some specific powerpc targets (405 for instance, but for 403
is also true) the -many flag causes problems. This is added when your compiler
command is something like:
powerpc-eabi-gcc -c -finline-limit=7000 -msoft-float -mcpu=405 -Wall
-Wpointer-arith -Wstrict-prototypes -Win
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:06 ---
Also note this worked with "4.0.0 2004121", so something after that date
changed the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:10 ---
Which binutils are you using because -many changed recently which is why it is
done this way in gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:11 ---
See the thread at http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01244.html to
see why -many was
added.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:12 ---
And http://sources.redhat.com/bugzilla/show_bug.cgi?id=147
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
--- Additional Comments From carlos at mind dot be 2005-04-18 18:13 ---
Subject: Re: -many flag causes problems
On Monday 18 April 2005 20:10, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
> 18:10 --- Which binuti
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:14 ---
In my mind MOT messed up by making two different instructions which have the
same opcode. Bad
MOT (freescale now).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
--- Additional Comments From carlos at mind dot be 2005-04-18 18:15 ---
Subject: Re: -many flag causes problems
On Monday 18 April 2005 20:11, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
> 18:11 --- See the thre
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:19 ---
(In reply to comment #8)
> Also note this worked with "4.0.0 20041211", so something after that date
> changed the problem.
And it was broken by "4.0.0 20050113". so there is only a month time which it
c
--- Additional Comments From jason at redhat dot com 2005-04-18 18:28
---
Subject: Re: local static object variable constructed once
but ctors and dtors called multiple times on same memory when called in
multiple threads
On 18 Apr 2005 09:07:00 -, "adah at netstd dot com" <[EMAI
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:34 ---
Looks like this was caused by:
2004-12-16 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/18905
* cp-tree.h (integral_constant_value): Declare.
* call.c (null_ptr_cst_p): Use integral_co
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:39 ---
Can you try this with today's compiler, I cannot reproduce it with it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21081
--- Additional Comments From sabre at nondot dot org 2005-04-18 18:41
---
Is this optimization valid? Note that it will change the behavior of this c++
program:
#include
static const double X = 1.0;
static struct S { S(); } s;
static const double Y = X+2.0;
S::S() {
printf("%
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:42 ---
This is a dup of one of the oldest "bug" in the database, PR 57.
Basically right now it might be a bug in GCC or GCC is correct in the standard,
the work around is the
following:
template< typename T1,typ
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
18:42 ---
*** Bug 21084 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
Summary|ICE in |[4.0/4.1 Regression] ICE in
|do_nonmember_using_decl |do_nonmember_using_decl
Target M
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:04 ---
Reduced testcase:
extern "C" signed int toupper(signed int __c) throw();
namespace std
{
template< typename a > a toupper(a,int){}
using ::toupper;
}
Note this has to do with builtin functions as if I
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:10 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:12 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:13 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:18 ---
On the mainline we don't get virtual memory exhausted but that is because there
has been a patch or
two to fix the memory usage but instead we get stack overflow:
#1207 0x002fc6e0 in fold_binary (code=TRUN
--
What|Removed |Added
Known to fail||4.0.0 4.1.0
Known to work||3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:24 ---
Reduced testcase:
int main( int argc, char * argv[ ] )
{
int maxstringlen = 1;
int limit = 0, maxblock = 0, maxblockrem = 0;
maxblockrem = (maxstringlen) % (2147483647 + 1);
}
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:25 ---
(In reply to comment #2)
> Reduced testcase:
Even though there is an overflow which the C front-end says the code was in an
if (0) block so it should
not matter about that as it is only undefined then but
--- Additional Comments From schlie at comcast dot net 2005-04-18 19:29
---
(In reply to comment #3)
> Simple code which shows we now have a missed optimization:
> static const double a = 1.0;
> static const double b = a+1.0;
>
> double c()
> {
> return b;
> }
>
> See PR 21089.
I be
--- Additional Comments From schlie at comcast dot net 2005-04-18 19:36
---
(In reply to comment #11)
I believe the optimization necessitates the variable's declaration be changed
(either explicitly, or by implication):
static const double b = a+1.0; => const double b = a+1.0;
If it'
A recent change on CVS HEAD breaks this:
$ cat a.cc
class X {
friend class Y;
friend int foo(const Y&);
};
$ g++ -c -W -Wall a.cc
a.cc:3: error: expected ',' or '...' before '&' token
a.cc:3: error: ISO C++ forbids declaration of 'Y' with no type
The original bug report is against CLN with pos
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:38 ---
Most likely caused by:
2004-07-05 Roger Sayle <[EMAIL PROTECTED]>
* fold-const.c (fold) : Optimize unsigned modulus
by a power of two into a bit-wise AND, i.e. "X % C" as "X & (C-1)".
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-18
19:40 ---
No, the code is invalid, as Y has not been interjected yet. This is a
progression and not a regression.
--
What|Removed |Added
-
Missed tail call optimization when local address could escape but not on the
condition:
void f(void);
void f1(int *);
void g(int i, int j)
{
if (j)
return f();
return f1(&i);
}
This might be a reduced testcase from fold_binary to fold_build2 where we have
this issue, but I have
not loo
n -O3
=== libmudflap Summary ===
# of expected passes1212
# of unexpected failures48
Compiler version: 4.0.0 20050418 (prerelease)
Platform: x86_64-unknown-linux-gnu
configure flags: --prefix=/home/guerby/tmp/install7/ --enable-__cxa_atexit
--disable-nls --enable-th
--- Additional Comments From phython at gcc dot gnu dot org 2005-04-18
20:15 ---
Created an attachment (id=8678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8678&action=view)
Don't alter overflowed constants
sign_bit_p returns false for overflowed constants, this is bad for thi
--- Additional Comments From bangerth at dealii dot org 2005-04-18 20:16
---
This code has at least two bugs:
template class MyType;
template <> std::map MyType::m_map;
First, the instantiation must come *after* the definition of the static
member.
Second, the definition you tho
--- Additional Comments From kreckel at ginac dot de 2005-04-18 20:19
---
(In reply to comment #1)
> No, the code is invalid, as Y has not been interjected yet. This is a
progression and not a regression.
Really? What about paragraph 11.4/7 "A name nominated by a friend
declaration sh
1 - 100 of 142 matches
Mail list logo
