/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.dg: 20050325-1.c
Log message:
PR rtl-optimization/20249
* cse.c (insert_regs): Do not record equivalence of registers in
different modes.
* gcc.dg/20050325-1.c: New test.
Patches:
http://gcc.gnu.org
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
09:27 ---
Subject: Bug 20249
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-25 09:27:37
Modified files:
gcc:
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-03-25
09:28 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
PR middle-end/20225 introduced a regression on the following testcase at -O2.
void fn1 (void *);
void fn2 (void *);
void foo (void);
void bar (void);
extern inline void *
baz (void)
{
return 0;
}
void
foo (void)
{
fn1 (baz ());
fn2 (baz ());
}
void
bar (void)
{
fn1 (baz ());
fn2
--
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Target Milestone|---
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-25 11:05
---
This patch introduced a regression, see PR20635.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
--
What|Removed |Added
CC||pluto at pld-linux dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20635
--- Additional Comments From caolanm at redhat dot com 2005-03-25 11:28
---
FWIW I only see it on ppc, though I compile with different optimization values
for i386, ppc command line is...
g++ -fsigned-char -fmessage-length=0 -c -I. -I. -I../inc -I../../inc
-I../../unx/inc
--- Additional Comments From pluto at pld-linux dot org 2005-03-25 12:37
---
(In reply to comment #3)
This looks like a bug in your installation of glibc.
#define INIT_SEGV \
do \
{
--
What|Removed |Added
OtherBugsDependingO||20225
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20635
I'm getting the following bootstrap failure on mainline with current CVS:
./xgcc -B./ -B/opt/gcc/4.1-devel/powerpc64-suse-linux-gnu/bin/ -isystem opt/gcc/
4.1-devel/powerpc64-suse-linux-gnu/include -isystem opt/gcc/4.1-devel/powerpc64-
suse-linux-gnu/sys-include -L/abuild/aj/gcc/gcc/../ld -O2
--- Additional Comments From aj at gcc dot gnu dot org 2005-03-25 13:02
---
This is defined on my x86-64 system:
grep sigaction /usr/include/bits/syscall.h
#define SYS_rt_sigaction __NR_rt_sigaction
#define SYS_sigaction __NR_sigaction
This looks like a problem on your side building
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
13:35 ---
Subject: Bug 19679
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-25 13:35:29
Modified files:
gcc/testsuite : ChangeLog
libgfortran:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
13:35 ---
Subject: Bug 19678
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-25 13:35:29
Modified files:
gcc/testsuite : ChangeLog
libgfortran:
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-03-25
13:37 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 19292 depends on bug 19678, which changed state.
Bug 19678 Summary: DOS files don't work for list directed input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19678
What|Old Value |New Value
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19678
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-03-25
13:38 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-25
13:41 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Mar 24, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
Combine doesn't ensure the subregs it generates are valid. In most
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
13:41 ---
Subject: Bug 19678
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-25 13:40:20
Modified files:
gcc/testsuite :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
13:41 ---
Subject: Bug 19679
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-25 13:40:20
Modified files:
gcc/testsuite :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
14:03 ---
I want to say this is the normal -fschedule-insns problem on i686-pc-linux-gnu
which is known to
cause problems. There is another bug about the same issue.
--
What|Removed
--- Additional Comments From pluto at pld-linux dot org 2005-03-25 14:05
---
(In reply to comment #5)
This is defined on my x86-64 system:
grep sigaction /usr/include/bits/syscall.h
#define SYS_rt_sigaction __NR_rt_sigaction
#define SYS_sigaction __NR_sigaction
This looks
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
14:23 ---
Caused by:
2005-03-13 David Edelsohn [EMAIL PROTECTED]
* config/rs6000/predicates.md (mem_or_easy_const_operand): Delete.
(reg_or_none500mem_operand): New predicate.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
14:30 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02336.html.
--
What|Removed |Added
--
What|Removed |Added
Component|tree-optimization |rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20634
--- Additional Comments From schwab at suse dot de 2005-03-25 15:06 ---
Linux/x86-64 does not have a sigaction syscall. But
nevertheless /usr/include/sys/syscall.h should define SYS_sigaction for
__WORDSIZE != 64 if you have the proper bi-arch headers installed.
--
Hi,
here is the bug,
root:/sources/psmisc-21.6# make
make all-recursive
make[1]: Entering directory `/sources/psmisc-21.6'
Making all in doc
make[2]: Entering directory `/sources/psmisc-21.6/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/sources/psmisc-21.6/doc'
This was hard to find. Consider this snippet:
--
struct B {
void f();
};
struct D : B {
using B::f;
B::f;
};
--
Note that D contains old- and new-style using declarations. In my case, they
were several hundred lines apart in D, so it wasn't
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
17:09 ---
Subject: Bug 19888
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-25 17:09:10
Modified files:
gcc/testsuite : ChangeLog
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
17:10 ---
This is not a GCC bug but a bug in your setup as explained by Andreas Schwab.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
17:13 ---
Comeau gives the following error:
ComeauTest.c, line 7: error: duplicate using-declaration of B::f ignored
B::f;
Confirmed.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
17:31 ---
Subject: Bug 15491
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-25 17:31:41
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
17:55 ---
Subject: Bug 15491
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-25 17:54:59
Modified files:
gcc: ChangeLog
gcc/config/vax :
--- Additional Comments From dank at kegel dot com 2005-03-25 18:29 ---
A patch to gcc-3.3.3 to do exactly what you're asking for was posted
by Dave Korn a few months ago, and approved in principle:
http://gcc.gnu.org/ml/gcc/2004-07/msg00798.html
I'll attach a copy of the patch here.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
18:31 ---
Subject: Bug 15491
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-03-25 18:30:58
Modified files:
gcc:
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-25
19:28 ---
Fixed in CVS.
--
What|Removed |Added
Status|WAITING
--
What|Removed |Added
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15491
The alloca builtin has the attribute __malloc__ set on it but GCC doesn't seem
to take advantage of that fact for optimization. The testcase gcc.dg/builtins-
13.c tests an optimization when calling the malloc/calloc functions. When I
try a similar case for alloca such as in the patch below,
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
20:08 ---
Subject: Bug 20470
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-25 20:08:33
Modified files:
gcc: ChangeLog fold-const.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-25
20:10 ---
Subject: Bug 20470
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-25 20:10:39
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From bangerth at dealii dot org 2005-03-25 20:12
---
I should add that it doesn't matter whether you use old- or new-style
using declarations:
B::f;
B::f;
and
using B::f;
using B::f;
yield the same results.
W.
--
I'm getting the following error.
claire:~/claire/gnu/b-sparc/gcc$ ./cc1 -da -O2 -quiet foo.c
foo.c: In function `foo':
foo.c:9: error: inconsistent operand constraints in an `asm'
The problem is store motion is deleting one of the asm volatile stores by
changing it to a store to a pseudo. grep
--- Additional Comments From redi at gcc dot gnu dot org 2005-03-25 20:38
---
This can be simplified to:
template class T void f()
{
T t;
t.f(0); //should be t.template f(0);
}
If either 'f' is renamed g++ correctly reports an error.
Comeau's online compiler behaves the same.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
20:40 ---
Confirmed, only a 3.4 regression.
It was fixed on the mainline:
: Search converges between 2004-09-28-161001-trunk (#566) and
2004-09-29-014002-trunk
(#567).
It broke on the mainline:
: Search converges
--
What|Removed |Added
Known to work||4.0.0 4.1.0
Summary|duplicate label for inlined |[3.4 only] duplicate label
static int a = 0;
extern int foo (void);
extern int *bar (void) __attribute__ ((__const__));
void
test (int x)
{
int b = 10;
while (foo () == -1 *bar () == 4 b 0)
--b;
a = x;
}
ICEs on i386 and x86_64 with -O2 -funroll-loops (and e.g. -O3
-fomit-frame-pointer -funroll-loops too).
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20640
Give the following code, we don't optimize it on the tree level:
typedef __SIZE_TYPE__ size_t;
extern void link_error();
extern void *f (size_t) __attribute__((__malloc__));
static int x;
void test3(void)
{
int *ptr1, *ptr2;
ptr1 = x;
ptr2 = (int*) f(sizeof (int));
*ptr1 = 12;
*ptr2 =
// This illustrates a problem with the gnu c compiler
// GCC (GCC) 3.3.3 (cygwin special)
// The problem is when printing a field of a struct with printf,
// the second value is zero.
#include stdio.h
#include stdlib.h
#include sys/stat.h
int main(int argc, char* argv[])
{
struct stat st;
--
What|Removed |Added
Keywords||alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20641
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
21:00 ---
Confirmed, I also noticed that we don't take advantage of the malloc attribute
on the tree level either,
see PR 20641.
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||20638
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20641
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
21:07 ---
Confirmed, for some reason on the mainline we are not unrolling the loop.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
21:08 ---
st.st_size is a long long so this is not a bug, try with -Wformat and you will
see a warning.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
21:11 ---
With checking enabled we get:
t.c: In function test:
t.c:7: error: PHI argument is missing for edge 1-4
for PHI node
a_13 = PHI a_11(2), a_14(3), (1);
t.c:7: internal compiler error: verify_ssa failed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
21:12 ---
And was happening when the 4.0 branch was created: 20050225.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20640
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
21:33 ---
I am about to post a patch for this one.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-25
21:39 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02391.html.
--
What|Removed |Added
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-25 22:06 ---
Subject: Re: Do not print default template arguments in error messages
giovannibajo at libero dot it [EMAIL PROTECTED] writes:
| --- Additional Comments From giovannibajo at libero dot it
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-25 22:09 ---
Subject: Re: Do not print default template arguments in error messages
giovannibajo at libero dot it [EMAIL PROTECTED] writes:
| The first non-trivial issue is that, in order to print std::vectorint
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-25 22:09 ---
Subject: Re: Do not print default template arguments in error messages
giovannibajo at libero dot it [EMAIL PROTECTED] writes:
| --- Additional Comments From giovannibajo at libero dot it
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-25 22:11 ---
Subject: Re: Do not print default template arguments in error messages
giovannibajo at libero dot it [EMAIL PROTECTED] writes:
| I cannot fix all the diagnostic problems in GCC with a single patch,
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-25 22:13 ---
Subject: Re: [3.3 only] gcc panic with __thread attribute
wilson at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Technically, this isn't a regression, as gcc-3.2 did not have TLS
| support, and
--- Additional Comments From janis at gcc dot gnu dot org 2005-03-25 22:21
---
This works with today's 4.0-branch sources, with small test cases and also
with eon built with this option. I haven't checked to see when it was
fixed, but this PR can now be closed.
--
In the attached test case, 3.4.* GCC generates better code than 4.0 (or 4.1)
because it moves more loop invariant code out of the inner loop of P7Viterbi.
The problem seems to be in the alias analysis which determines what can be moved
out of that loop. If you change the field M, which is
--
What|Removed |Added
Keywords||alias, missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
The warning below is inappropriate since j can never be used in the function.
$ cat t.cpp gcc -c -O -W t.cpp
int foo ()
{
int i;
int j;
for ( ; ; ) {
i = 0;
if (0 == i)
break;
}
if (1 == i)
return j;
return 0;
}
t.cpp: In function
When this function is compiled with -O, it works. When it's compiled without -O,
it reports error error: can't find a register in class `GENERAL_REGS' while
reloading `asm'.
I think that syntactic corectness of language shouldn't depend on optimization
flags --- it should either report error in
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-26
00:02 ---
Subject: Re: New: Tree loop optimizer does
worse job than RTL loop optimizer
On Fri, 2005-03-25 at 22:21 +, sje at cup dot hp dot com wrote:
In the attached test case, 3.4.* GCC generates
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26
00:29 ---
*** This bug has been marked as a duplicate of 11203 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26
00:29 ---
*** Bug 20645 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-03-26
00:30 ---
(In reply to comment #14)
| The first patch will deal with just removal of default
| arguments, and I believe that the less intrusive and clean solution is to
| display default in the with clause.
--- Additional Comments From giovannibajo at libero dot it 2005-03-26
00:35 ---
(In reply to comment #12)
Look at the most general template and same_type_p() with any default
type.
How can it work? The default parameter can be dependent on previous template
parameters. For
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26
00:43 ---
I think we had decided even though the code is unreachable, we want to warn
about this.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26
00:48 ---
And as I have mentioned in the email, do-loop is not being done because well it
would be invalid to do
it as we change an infinite loop to a finite one, see PR 19210.
--
Could someone help me understand what's causing the following
warning so that I can silence it? Gcc 3.4.3 emits it for an
implicitly inline one-line definition of the function (ctor,
actually, see below), so I'm not sure what the function body
not available bit is supposed to mean. The base ctor
--- Additional Comments From sebor at roguewave dot com 2005-03-26 01:08
---
I can imagine that it may not be straightforward to fix but I can't think of a
reason why a warning could ever be useful in this case (i.e., when the code is
provably safe). I could of course be missing
On Mar 25, 2005, at 7:59 PM, Martin Sebor wrote:
Could someone help me understand what's causing the following
warning so that I can silence it? Gcc 3.4.3 emits it for an
implicitly inline one-line definition of the function (ctor,
actually, see below), so I'm not sure what the function body
not
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26
01:13 ---
(In reply to comment #2)
I can imagine that it may not be straightforward to fix but I can't think of a
reason why a warning could ever be useful in this case (i.e., when the code is
provably safe). I
Andrew Pinski wrote:
On Mar 25, 2005, at 7:59 PM, Martin Sebor wrote:
Could someone help me understand what's causing the following
warning so that I can silence it? Gcc 3.4.3 emits it for an
implicitly inline one-line definition of the function (ctor,
actually, see below), so I'm not sure what
--- Additional Comments From dave at boost-consulting dot com 2005-03-26
02:01 ---
Subject: Re: Do not print default template arguments in error messages
gdr at integrable-solutions dot net [EMAIL PROTECTED] writes:
--- Additional Comments From gdr at integrable-solutions dot
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-26 04:04 ---
Subject: Re: Do not print default template arguments in error messages
giovannibajo at libero dot it [EMAIL PROTECTED] writes:
| --- Additional Comments From giovannibajo at libero dot it
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-26 04:06 ---
Subject: Re: Do not print default template arguments in error messages
giovannibajo at libero dot it [EMAIL PROTECTED] writes:
| --- Additional Comments From giovannibajo at libero dot it
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-26 04:13 ---
Subject: Re: Do not print default template arguments in error messages
dave at boost-consulting dot com [EMAIL PROTECTED] writes:
[...]
| Please, I'm begging you not to go down this road. GCC is
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-26 04:20 ---
Subject: Re: error: 'anonymous enum' is/uses anonymous type'
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| Intuitively, C++ treats unnamed enums differently than named ones, because
| in
--- Additional Comments From gdr at integrable-solutions dot net
2005-03-26 04:28 ---
Subject: Re: New: [3.3/3.4/4.0/4.1 regression] Confusing message with
different using declarations
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| This was hard to find. Consider this
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-12-25
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26
05:38 ---
http://gcc.gnu.org/wiki/Add%20MEM_REF%20operation
--
What|Removed |Added
--- Additional Comments From aj at gcc dot gnu dot org 2005-03-26 06:31
---
Close as suggested
--
What|Removed |Added
Status|UNCONFIRMED
I don't know what I was thinking when I wrote this, but the following illegal
code (.ii, tiny testcase) causes an ICE in g++-4.0 which was not present in 3.4:
# 1 extern-static.cpp
# 1 built-in
# 1 command line
# 1 extern-static.cpp
struct foo {
extern static int i;
};
int main () {
return 0;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26
07:32 ---
Confirmed, an error recovery problem, not a release blocking regression for
4.0.0, setting target
milestone to 4.0.1 as per Mark, the Release manager.
--
What|Removed
93 matches
Mail list logo
