--- Comment #4 from lisp2d at lisp2d dot net 2008-12-25 05:41 ---
If commands if and ?: operate on a miscellaneous.
Not clearly when works copyconstructor and when there is no.
class A{public:intx;A():x(0){};};
class B:publicA{public:inty;B():A(),y(0){};};
class C:
--- Comment #3 from kkojima at gcc dot gnu dot org 2008-12-25 03:38 ---
Here is an another reduced testcase.
struct s
{
char a[512];
int b;
int c;
};
long long
foo (struct s *p, int m, int r)
{
if (r == m)
p->b = 3;
p->c = 1;
return m;
}
I've confirmed that this fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-25 03:00 ---
This is an dup of bug 36296.
This happens after SRAing of some variables which shows up that PR again.
*** This bug has been marked as a duplicate of 36296 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-12-25 03:00
---
*** Bug 37361 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 2008-12-25 02:47 ---
Note GCC might be still be implementing pre-standard (ARM) using behavior in
some cases, this might be one of those cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37374
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-25 02:36 ---
Has this been fixed now?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36214
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-25 01:44 ---
The trunk accepts this code ...
The 4.3 branch rejects this code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37468
--- Comment #1 from liqin at gcc dot gnu dot org 2008-12-25 01:20 ---
score binutils will checkin this option soon.
--
liqin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-25 01:05 ---
You still need a definition of X::VAL1, you only have a declaration of it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
For the following code, one has the following:
g++ main.cpp : undefined reference to `X::VAL1'
g++ main.cpp -O3 : links O.K.
--main.cpp--
struct X { static const int VAL1 = 17; };
int func1( const int aVal ) { }
int func2( cons
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-24 23:15 ---
No feedback in 3 months and the user did not have binutils in the source tree
or installed so closing as works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-24 23:16 ---
>makes memory crash
What do you mean by makes memory crash. also what version of GCC are you
using? And what do you behavior do you get from GCC and what do you expect to
get?
--
pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-24 23:12 ---
No feedback from the user in 3 months and it was reported against redhat's
source so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-24 23:11 ---
No feedback in 3 months and it works for me so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-24 23:09 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-24 23:08 ---
No source 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 2008-12-24 23:08 ---
No answer 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 2008-12-24 23:07 ---
No answer 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 2008-12-24 23:14
---
This is not useful as sometimes it is hard to point out the one C99/C++98 which
tells you why your code is invalid, in some cases you need to point to 3
different locations in the standard and read that. An exampl
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-24 23:06 ---
No answer in 3 months so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-12-24 23:06 ---
No answer in 3 months 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 2008-12-24 23:00 ---
(In reply to comment #3)
> Did you made sure that this is not a ppc machine/cost description problem?
This sounds like what the patch which I mentioned in
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01323.html .
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-24 22:52 ---
Invalid as amiga OS is not a supported target.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37527
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-24 20:32 ---
*** This bug has been marked as a duplicate of 38622 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-24 20:32 ---
*** Bug 38623 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38622
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-24 20:31 ---
This works for me, the code is valid as xa is converted into B via a
copyconstructor and then that is converted into a via the copy constructor.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38622
class A{public:intx;A():x(0){};};
class B:publicA{public:inty;B():A(),y(0){};};
A debugg(){
A xa;
B xb;
return (false?xa:xb);}
makes memory crash
--
Summary: operator ?: Does not check identity of types
Pro
class A{public:intx;A():x(0){};};
class B:publicA{public:inty;B():A(),y(0){};};
A debugg(){
A xa;
B xb;
return (false?xa:xb);}
makes memory crash
--
Summary: operator ?: Does not check identity of types
Pro
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-24 20:20 ---
Confirmed,
t.cc: In function 'void f() [with U = char, T = ]':
t.cc:9: instantiated from here
t.cc:5: internal compiler error: tree check: accessed elt 1 of tree_vec with 0
elts in get_innermost_template_args, at c
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-24 20:11 ---
Reduced testcase:
const int a = 1;
template void f() {
f<>();
}
-- CUT ---
Works with a struct though.
Confirmed, not a regression
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-24 19:13 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37766
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-24 18:24
---
This works for me:
--- ./c-lex.c.fixed 2008-08-21 05:32:03.0 -0700
+++ ./c-lex.c 2008-12-24 10:23:52.0 -0800
@@ -612,7 +612,15 @@ interpret_float (const cpp_token *token,
/* Decode _Fract
--- Comment #3 from jon at beniston dot com 2008-12-24 18:21 ---
This is a port to a new target I am working on, so thanks for investigating.
Are you saying that PARAM_BOUNDARY and STACK_BOUNDARY must be >=
BIGGEST_ALIGNMENT?
Looking through the other ports it appears this may not be
--- Comment #9 from joseph at codesourcery dot com 2008-12-24 18:01 ---
Subject: Re: ICE passing fixed point to function
On Wed, 24 Dec 2008, hjl dot tools at gmail dot com wrote:
> I verified that there is
>
> auto-host.h:#define ENABLE_FIXED_POINT 0
>
> But I still got ICE:
Then
--- Comment #8 from hjl dot tools at gmail dot com 2008-12-24 17:59 ---
It seemslike even if fixed point isn't supported, gcc still
recognizes "0r".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38617
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-24 17:55 ---
I verified that there is
auto-host.h:#define ENABLE_FIXED_POINT 0
But I still got ICE:
bash-3.2$ cat /tmp/f.c
extern void foo(Fract);
int main()
{
foo(0r);
}
bash-3.2$ ./xgcc -B./ -S /tmp/f.c
/tmp/f.c:1: warni
--- Comment #6 from cfairles at gcc dot gnu dot org 2008-12-24 17:33
---
(In reply to comment #5)
> Subject: Re: ICE passing fixed point to function
>
> If they didn't configure with that option the compiler should give
> sensible errors rather than ICEs.
>
> I don't know which is th
--- Comment #5 from joseph at codesourcery dot com 2008-12-24 17:28 ---
Subject: Re: ICE passing fixed point to function
On Wed, 24 Dec 2008, pinskia at gcc dot gnu dot org wrote:
> x86_64 does not support fixed point modes at all. Someone needs to come up
> with an ABI for it.
If t
--- Comment #15 from pault at gcc dot gnu dot org 2008-12-24 17:08 ---
(In reply to comment #13)
Dear Dominique,
> print *, len(string)
> print *, size(transfer(string,"xy",len(string)))
> yields a wrong code: the executable gives
>
>8
>4
> ab
--- Comment #5 from pluto at agmk dot net 2008-12-24 17:02 ---
(In reply to comment #4)
> Not a GCC bug, please report this to the binutils project which controls ld.
>
link failure with --as-needed is not a linker bug.
it's strictly related to bugs in makefiles.
i'll analyze gcc build
--- Comment #7 from ajs1 at cam dot ac dot uk 2008-12-24 16:46 ---
I have downloaded the latest version of gfortran from
gcc.gnu.org/wiki/GFortran, and it seems to be working nicely. Previously I had
followed the link from hpc.sourceforge.net, which I now see is at least a year
out of da
--- Comment #4 from cfairles at gcc dot gnu dot org 2008-12-24 16:44
---
(In reply to comment #3)
> What are fixed point types?
http://gcc.gnu.org/wiki/FixedPointArithmetic
--
cfairles at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-24 16:20 ---
What are fixed point types? What need to implement to support fixed
point types? Does gcc testsuite have any fixed point tests?
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-24 15:44 ---
Works for me also on i386-darwin8.11 with 4.3.3 and 4.4.0.
So closing as fixed.
Most likely it is caused by:
DO 30 IORD = NINT(DRTAXS(4,1)),2,-1
Which means this is a dup of bug 34026.
*** This bug has be
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-24 15:44 ---
*** Bug 38618 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from tammer at tammer dot net 2008-12-24 15:45 ---
Hello,
in addition to IBM XLC/C++ V9 I have tried gcc 4.2.4 (from www.perzl.org) to
bootstrap 4.2.4. The error is always the same. The build finishes but according
to the log the libstdc++.so.6 is not OK.
I have used the
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-24 15:39 ---
(In reply to comment #4)
> One thing is strange is the config: --enable-languages=fortran,c++. What about
> c? It is the first time I notice a build of gfortran without C. Is it implied
> by c++?.
C is always includ
--- Comment #4 from dominiq at lps dot ens dot fr 2008-12-24 15:36 ---
Midair collision! I was about to send:
The test in comment#2 compiles fine for me on i686-apple-darwin9 with the
options I have tried with gfortran 4.2.3, 4.3.2, and 4.4.0 (trunk).
One thing is strange is the config
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-12-24 15:32 ---
Thanks for the quick response!
The attached file compiles fine for me with 4.3.2 and 4.4.0 on
i686-pc-linux-gnu. Dominique, could you give the test a spin on darwin?
Btw, the binary packages have been updated only
--- Comment #6 from socketpair at gmail dot com 2008-12-24 15:28 ---
> -fno-fstack-protector is a work around. Ubuntu must enable stack protector by
default.
I don't understand. Ubuntu enabled stack protector by default now. Is this
error?
Should i report bug to Ubuntu?
It stack pro
--- Comment #5 from socketpair at gmail dot com 2008-12-24 15:21 ---
-fno-stack-protector really helps.
i don't understand why "rep stosl" appear in the middle of string
initialization..
gdb said that "rep stosl" is a cause of zero byte after first 8 symbols.
also, if this bug does not
--- Comment #2 from ajs1 at cam dot ac dot uk 2008-12-24 15:20 ---
Created an attachment (id=16982)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16982&action=view)
Fortran subroutine
This is a simplified and cleaned-up version of the file, which still triggers
the bug, with the c
--- Comment #2 from vapier at gentoo dot org 2008-12-24 15:02 ---
Created an attachment (id=16981)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16981&action=view)
gdevifno.orig.i
here's the original file in case the reduced test case is troublesome
--
http://gcc.gnu.org/bugz
--- Comment #1 from vapier at gentoo dot org 2008-12-24 14:59 ---
Created an attachment (id=16980)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16980&action=view)
gdevifno.i
$ sh4-unknown-linux-gnu-gcc -c gdevifno.i -O2
gdevifno.i: In function inferno_rgb2cmap:
gdevifno.i:41: e
when building ghostscript-gpl-8.63, gcc-4.3.2 fails:
sh4-unknown-linux-gnu-gcc -DHAVE_MKSTEMP -DHAVE_HYPOT -DHAVE_FILE64
-DHAVE_MKSTEMP64 -DHAVE_FONTCONFIG -O2 -Wall -Wstrict-prototypes -Wundef
-Wmissing-declarations -Wmissing-prototypes -Wwrite-strings
-Wno-strict-aliasing -fno-builtin -fno-comm
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-12-24 14:34 ---
I have difficulties to reproduce.
Could you please try an up-to-date version of gfortran and see if the problem
persists? If yes, please attach a source file that triggers the compiler error
and state the exact fla
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-24 14:17 ---
Confirmed, a regression from at least 4.1.1, I have not tried 4.2.x yet.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-24 14:10 ---
Related to PR 11407 and PR 10690.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
$ cat test.cpp
template
void foo(T x)
{
}
void bar()
{
decltype(foo) dt;
}
$ g++ -std=gnu++0x -c test.cpp
test2.cpp: In function 'void bar()':
test2.cpp:9: internal compiler error: in finish_decltype_type, at
cp/semantics.c:4193
This fails on mingw 4.3.0 and fresh svn on linux.
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-24 13:57 ---
-fno-fstack-protector is a work around. Ubuntu must enable stack protector by
default.
Note it works on the trunk but fails on an older 4.3.3:
gcc version 4.3.3 20081218 (prerelease) [gcc-4_3-branch revision 142804
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-24 13:54 ---
x86_64 does not support fixed point modes at all. Someone needs to come up
with an ABI for it.
Note it works in 32bit mode ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-24 13:49 ---
Not a GCC bug, please report this to the binutils project which controls ld.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from socketpair at gmail dot com 2008-12-24 13:38 ---
(From update of attachment 16979)
(i'm not intentionally send assembler output for version where buf[1024]
replaced with buf[1023]).
--
socketpair at gmail dot com changed:
What|Removed
--- Comment #2 from socketpair at gmail dot com 2008-12-24 13:33 ---
(From update of attachment 16979)
.file "zzz2.c"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl
--- Comment #1 from socketpair at gmail dot com 2008-12-24 13:27 ---
Created an attachment (id=16979)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16979&action=view)
assembler output of wrong generated code
this assembler output generates only 8 characters in output instead of fu
--- Comment #3 from pluto at agmk dot net 2008-12-24 12:57 ---
passing -Wl,--as-needed to LDFLAGS_FOR_TARGET causing this failure.
4.3 works fine with --as-needed.
--
pluto at agmk dot net changed:
What|Removed |Added
--
The types in modules A and B are different as per F95 4.4.2 (same name, same
components but not SEQUENCE). The error "Can't convert TYPE(ta) to TYPE(ta)" is
not very helpful in this case.
$> cat sametype.f90
MODULE a
TYPE :: ta
INTEGER :: i
END TYPE
END MODULE
MODULE b
TYPE :: ta
IN
The command line and the resulting error messages:
gfortran -I../include -Wall -save-temps -DVAR_G77 -DSYS_LINUX -DVAR_MFDS
-DVAR_SPLITFILES -D'INSTALL_WRKMEM=2000'
-D'INSTALL_BASDIR="/Users/ajs1/Dalton-2.0/basis/"' -O2 -std=legacy -ffast-math
-fexpensive-optimizations -funroll-loops -c abavrml
/gcc/gnu-trunk/i686-pc-linux-gnu/install
--with-included-gettext
Thread model: single
gcc version 4.4.0 20081224 (experimental) (GCC)
foo.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e24dd004sub sp, sp, #4 ; 0x4
4: e52db004push
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16620, 16989
nThis||
--- Comment #1 from cfairles at gcc dot gnu dot org 2008-12-24 12:00
---
cc'ing andrew
--
cfairles at gcc dot gnu dot org changed:
What|Removed |Added
CC
template
void foo(T) { } // 2
int main()
{
foo(0r); // 6
}
Gives:
fixed.cpp: In function 'void foo(T) [with T = ]':
fixed.cpp:6: instantiated from here
fixed.cpp:2: internal compiler error: in classify_argument, at
config/i386/i386.c:5123
Chris
--
Summary: ICE passing fixed f
I'm using generic Ubuntu Intrepid desktop i386 system.
My program:
#include
int main (void)
{
char buffer[1024]="";
sprintf (buffer, "%s", "1234567890abcdefghijklmno");
printf ("%s\n", buffer);
return 0;
}
--
It will print '12345678' if -O2 or -O3 is used. If
--- Comment #5 from tammer at tammer dot net 2008-12-24 11:13 ---
Hello,
the patch did not affect this problem.
I have started a new build without the patch and the problem is still the same.
I especially do not understand why the linker call for libstdc++.so.6 ends in
${wl}-berok and
79 matches
Mail list logo
