--- Comment #3 from pault at gcc dot gnu dot org 2007-01-28 08:03 ---
Tobias,
The error occurs when the symbol hessian is written.
The error is gone if one removes the : only ENERGY_CONSTRAINT or the use
atoms from the POTENTIAL_ENERGY module (if you have {atom,constraint}.mod
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-01-28 10:45 ---
Subject: Bug 30389
Author: tkoenig
Date: Sun Jan 28 10:44:47 2007
New Revision: 121255
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121255
Log:
2007-01-28 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #3 from irar at il dot ibm dot com 2007-01-28 10:45 ---
The current versions of both mainline and autovect branch do not ICE. Strided
loads are not implemented for SSE. I opened a PR 30211 for it.
I think this PR can be closed.
Ira
--
irar at il dot ibm dot com
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE on frtl-abstract- |ICE on frtl-abstract-
|sequences and mthumb.
--- Comment #3 from irar at il dot ibm dot com 2007-01-28 11:38 ---
I tried to reproduce this on x86 with current autovect branch and mainline with
.../g++ -fpreprocessed tmp.ii -S -O3 -ftree-vectorize -msse2 -ansi
-fdump-tree-vect-details. It doesn't not ICE, and the loop is
=\ 20070128\ \
-DDEVPHASE=\ (prerelease)\ -combine
In file included from ../../../src/gcc-4.2.orig/gcc/coverage.h:25,
from ../../../src/gcc-4.2.orig/gcc/coverage.c:42:
../../../src/gcc-4.2.orig/gcc/gcov-io.h:284:22: error: gcov-iov.h: No such file
or directory
--- Comment #1 from aldot at gcc dot gnu dot org 2007-01-28 11:45 ---
I assume that this works with 4.1 but did not verify. If so, that's obviously a
[4.2 Regression]
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from patchapp at dberlin dot org 2007-01-28 12:30 ---
Subject: Bug number PR30554
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02282.html
--
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-28 13:40 ---
It looks like it is mine.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
I have a simple C file (almost hello world), with a very big formula inside.
If the formula gets too big, i get the following error message, which seems to
be wrong:
$ gcc s3.c
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab):
undefined reference to [EMAIL
--- Comment #3 from drow at gcc dot gnu dot org 2007-01-28 14:08 ---
Subject: Bug 30469
Author: drow
Date: Sun Jan 28 14:08:13 2007
New Revision: 121257
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121257
Log:
PR bootstrap/30469
* Makefile.in (CFLAGS): Forcibly
--- Comment #4 from drow at gcc dot gnu dot org 2007-01-28 14:08 ---
Fixed.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from capiman at clibb dot de 2007-01-28 14:08 ---
Created an attachment (id=12974)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12974action=view)
File to reproduce the error
I just used
gcc s3.c
inside cygwin environment and this produces the error.
Leaving out
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30486
char p;
int main() {
p = str;
return 0;
}
If anyone will try to assign something to p[0] and if rodata is write
protected,
we'll segfault. Assembly:
.file t.c
.section.rodata.str1.1,aMS,@progbits,1
.LC0:
.string str
.text
.globl main
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-28 16:10 ---
String literals are not writable.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30121
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30486
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-28 17:13 ---
More to the point, at one time in the past, GCC had an option to turn
(constant) string literals into readwrite strings, that was removed in 4.0.0
(maybe even in 3.4.0). Also the standard says they are constant
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-28 17:17 ---
I have a patch bootstrapped and regression tested that implements my version
but I am sure it will require minimal changes to implement whatever is decided.
So if you don't get an answer here, please raise the issue
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-28 17:23 ---
I will submit two patches. The first one will remove the function. Then, I have
to regtest the second one: perhaps we find another unused function!
Steven, if you really think that the case:
static void foo(void)
{
--- Comment #3 from vda dot linux at googlemail dot com 2007-01-28 17:25
---
Sorry! Bug in the testcase, should be char *p.
I remember that string literals are special - they decay to const char * OR
to char* depending on context. In this context, it should decay to char*,
and it does
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-28 17:31 ---
(In reply to comment #3)
Sorry! Bug in the testcase, should be char *p.
I remember that string literals are special - they decay to const char * OR
to char* depending on context. In this context, it should decay
--- Comment #5 from vda dot linux at googlemail dot com 2007-01-28 17:40
---
http://david.tribble.com/text/cdiffs.htm#C99-string-const
In C, string literals have type char[n], but are not modifiable (i.e.,
attempting to modify the contents of a string literal is undefined behavior).
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-28 18:09 ---
Subject: Bug 28988
Author: pinskia
Date: Sun Jan 28 18:09:25 2007
New Revision: 121261
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121261
Log:
2007-01-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-28 18:19 ---
Subject: Bug 28988
Author: pinskia
Date: Sun Jan 28 18:18:54 2007
New Revision: 121263
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121263
Log:
2007-01-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-28 18:19 ---
Subject: Bug 28988
Author: pinskia
Date: Sun Jan 28 18:18:54 2007
New Revision: 121263
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121263
Log:
2007-01-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-01-28 18:19
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
templatetypename T struct foo1 { T* next; };
struct foo2 : public foo1foo2 {};
struct foo3 : public foo1foo3, public foo2 {using foo1foo3::next;};
int main() { foo3 f; f.next = 0; }
gets you:
~$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:5: error: request for member 'next' is
--- Comment #8 from pinskia at gmail dot com 2007-01-28 19:04 ---
Subject: Re: newlib targets ICEs in
expand_builtin_int_roundingfn
On Wed, 2007-01-24 at 14:22 +, rguenth at gcc dot gnu dot org wrote:
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-01-24
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-28 19:10
---
(In reply to comment #10)
The patch is able to pass bootstrap but I still have another regression I need
to look into, dealing with an inline-asm and the testcase is x86 specific one
at that. (it does #ifdef
--- Comment #15 from pcarlini at suse dot de 2007-01-28 19:10 ---
FYI: I'm right now auditing the code for conversions larger - smaller integer
type and immediately adjusting it in the process. Only very few so far. To be
clear, I'm punting on conversions between same size types which,
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-28 19:15 ---
This is just an ODR (one definition rule) violation which does not need to be
diagnostic. In fact it might be hard to diagnostic this problem.
C++ defines inline functions as weak/varge linkage so the definition
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|gcj doesn't accept -Wall and|[4.3 Regression] gcj doesn't
|-Werror anymore
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-28 19:20 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-28 19:26 ---
I can reproduce this ICE but it is very hard to see where the problem is with
such a long testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-28 19:29 ---
*** This bug has been marked as a duplicate of 22456 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-28 19:29 ---
*** Bug 30575 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
templatetypename T struct foo { T*bar(); };
struct foo1 : public fooint, public foobool* { };
int main() { foo1 f; f.barint(); }
gets you:
~/foo$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:3: error: request for member 'bar' is ambiguous
foo.cc:1: error: candidates are: T*
--- Comment #1 from pluto at agmk dot net 2007-01-28 19:41 ---
(In reply to comment #0)
templatetypename T struct foo { T*bar(); };
struct foo1 : public fooint, public foobool* { };
int main() { foo1 f; f.barint(); }
this is an invalid code.
1). f.bar isn't a function template,
--- Comment #16 from manu at gcc dot gnu dot org 2007-01-28 19:47 ---
(In reply to comment #15)
FYI: I'm right now auditing the code for conversions larger - smaller integer
type and immediately adjusting it in the process. Only very few so far. To be
clear, I'm punting on
--- Comment #2 from igodard at pacbell dot net 2007-01-28 20:03 ---
I thought (according to the ARM) that all functions of a template class were
implicitly function templates. Ordinarily the correct instantiation is
determined by the object, but when both are inherited then it needs
--- Comment #3 from rwgk at yahoo dot com 2007-01-28 20:03 ---
I've repeated my test with
g++ (GCC) 4.2.0 20070128 (prerelease)
SVN revision: 121258
on three platforms:
x86_64 Fedora Core release 5 (Bordeaux)
% g++ -fPIC -O3 dbg_gcc_bugzilla_30567.cpp
% ./a.out
1
--- Comment #17 from pcarlini at suse dot de 2007-01-28 20:05 ---
(In reply to comment #16)
I think that we agreed that people using -Wconversion do want warnings for
larger-smaller conversions. When you mention same size types, do you mean
conversions between signed and unsigned
--- Comment #18 from pcarlini at suse dot de 2007-01-28 20:10 ---
(In reply to comment #16)
I am also interested in how many (negative constant)-unsigned conversions you
have found, because I would like to keep those in Wconversion as they have
always been.
None. If you are positive
--- Comment #8 from paolo at gcc dot gnu dot org 2007-01-28 20:12 ---
Subject: Bug 30586
Author: paolo
Date: Sun Jan 28 20:12:40 2007
New Revision: 121271
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121271
Log:
2007-01-27 Paolo Carlini [EMAIL PROTECTED]
PR
This:
type :: a
real :: r = 3.14159
integer :: i = 42
end type a
type(a), target :: dt(2)
integer, pointer :: ip(:)
ip = dt%i
print *, ip
end
produces
$ ./a
107853 42
with gfortran, whereas the correct result should be two 42s
Paul
--
Summary: Array pointers to
--- Comment #8 from muntyan at tamu dot edu 2007-01-28 20:15 ---
Is the code here or in comment #2 the same as in 30542 and 30575? It may be,
but gcc users who don't know gcc internals (like me), can't easily see this,
and missing warning (in those two bugs, not here) is quite a serious
--- Comment #9 from pcarlini at suse dot de 2007-01-28 20:23 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-28 20:33 ---
Confirmed.
Is this related to PR 29606?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2007-01-28
22:04 ---
(In reply to comment #2)
i.e. it misses to initialize the temporary with the result. Otherwise you
can play with variants of the following patch:
Richard, have you tried to make this patch work? It
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-28 22:15
---
In the spirit of Paul's suggestion. I will try this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-01-28 22:17 ---
Well, it fails in interesting ways if I remember correctly and no, I'm not
looking into this at the moment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-01-28 22:39 ---
Should we commit the combined fix? I do think this
is a bug.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-28 22:55 ---
We get:
main:
leal4(%esp), %ecx
andl$-16, %esp
movl$118, %edx
movl%edx, %eax
pushl -4(%ecx)
#APP
addb %dl, %al
#NO_APP
pushl %ebp
#APP
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-28 22:57
---
(In reply to comment #11)
SRA messes up somehow and it only happens with inlined functions so I am going
to look more into it.
I have a fix for the SRA issue now, SRA tries to look into 3rd/4th operand to
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-28 23:31 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-28 23:33 ---
Ubuntu uses a broken library layout so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-28 23:35 ---
make[7]: *** [compile-classes] Illegal instruction
At this point I am going to consider this a problem in the hardware you are
using as one, this works for me with the trunk and also the 4.1 branch on good
known
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-01-29 00:00
---
Richard, this patch is OK for 4.1, 4.2 branches once applied to mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
--- Comment #2 from kevin at penguinnetwerx dot net 2007-01-29 00:05
---
(In reply to comment #1)
How much memory do you have? This internal error is caused by the kernel
killing the process because it ran over the memory limits.
That would be the case. The box has 128MB of RAM.
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-29 00:12 ---
A possible work around is to create another temp variable of type struct test.
Such that the function test looks like:
struct test
test (void)
{
struct test result;
struct test temp;
result.type = 0;
for
--- Comment #2 from tobi at gcc dot gnu dot org 2007-01-29 00:16 ---
Wasn't there a bug for byte-sized strides in array descriptors? This bug
should depend on it, and PR29606 as well.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|natVMURLConnection.cc:21: |[4.3
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-29 00:33 ---
Does adding --param ggc-min-expand=0 --param ggc-min-heapsize=0 help you be
able to reproduce it with -save-temps? If it does please attach the
preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-29 00:51 ---
Sample backtrace:
#0 topo_visit (graph=0x9d55760, ti=0x9d55750, n=80) at
/src/gcc/regressions1/gcc/gcc/bitmap.h:388
#1 0x083a4312 in topo_visit (graph=0x9d55760, ti=0x9d55750, n=79)
at
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-29 01:10 ---
Pawel, I don't want to appear rude but as you see from the answers in the ML,
control might reach the end of the function without an explicit return. Thus,
the warning is valid and I think we should close this as
--- Comment #2 from bangerth at dealii dot org 2007-01-29 01:15 ---
In fact, after minor code changes, I can no longer reproduce the exact
sources that triggered this. I'll close it for the moment, and try
again if the problem should re-appear at one point...
W.
--
bangerth at
--- Comment #6 from sayle at gcc dot gnu dot org 2007-01-29 03:27 ---
Subject: Bug 30404
Author: sayle
Date: Mon Jan 29 03:27:07 2007
New Revision: 121279
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121279
Log:
PR fortran/30404
* trans-stmt.c (forall_info):
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-29 07:50 ---
(In reply to comment #2)
Wasn't there a bug for byte-sized strides in array descriptors? This bug
should depend on it, and PR29606 as well.
Both of you are right about PR29606. The byte-sized strides I do not
70 matches
Mail list logo
