--- 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
--- 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=gcc&view=rev&rev=121279
Log:
PR fortran/30404
* trans-stmt.c (forall_info): R
--- 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 deali
--- 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 INVALI
--- 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 /src/gcc/regressions1/gcc
--- 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:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|natVMURLConnection.cc:21: |[4.3 Regression
--- 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
---
--- 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 (in
--- 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 RA
--- 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 #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 har
--- 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 #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 #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
deci
--- 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 #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 #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 #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 #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 s
--- 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 #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 #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
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 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=gcc&view=rev&rev=121271
Log:
2007-01-27 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- 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 posit
--- 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 #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
--- 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
qual
--- 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 convers
--- Comment #1 from pluto at agmk dot net 2007-01-28 19:41 ---
(In reply to comment #0)
> template struct foo { T*bar(); };
> struct foo1 : public foo, public foo { };
> int main() { foo1 f; f.bar(); }
this is an invalid code.
1). f.bar isn't a function template, so f.bar is wrong.
template struct foo { T*bar(); };
struct foo1 : public foo, public foo { };
int main() { foo1 f; f.bar(); }
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* foo::bar() [with T = bool*]
foo
--- 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
---
--- 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 #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 #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
Statu
--
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 #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 of
--- 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 #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 #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 1
template struct foo1 { T* next; };
struct foo2 : public foo1 {};
struct foo3 : public foo1, public foo2 {using foo1::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 ambiguous
foo.cc:1: error: cand
--- 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
Status|ASSIGNE
--- 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=gcc&view=rev&rev=121263
Log:
2007-01-28 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- 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=gcc&view=rev&rev=121263
Log:
2007-01-28 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- 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=gcc&view=rev&rev=121261
Log:
2007-01-28 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- 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 #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 shoul
--- 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 i
--- 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 #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 at
--- 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 stri
--
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
--
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
--- 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
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 ma
--
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
--- 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=12974&action=view)
File to reproduce the error
I just used
gcc s3.c
inside cygwin environment and this produces the error.
Leaving ou
--- 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 #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=gcc&view=rev&rev=121257
Log:
PR bootstrap/30469
* Makefile.in (CFLAGS): Forcibly
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 PROTECTED
--- 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
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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
ASEVER="\"4.2.0\"" -DDATESTAMP="\" 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:
..
--- 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 vectorized.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE on frtl-abstract- |ICE on frtl-abstract-
|sequences and mthumb. |s
--- 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 changed:
--- 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=gcc&view=rev&rev=121255
Log:
2007-01-28 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- 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}.m
70 matches
Mail list logo
