--- Comment #5 from ubizjak at gmail dot com 2009-07-23 07:03 ---
(In reply to comment #4)
> > What happens if you use gas instead of Sun's assembler?
>
> $HOME/gnu-x86/local/bin/gfortran -c site.f90 -march=k8 -m32 -S
> gas --32 site.s
> site.s:652: Error: invalid character '.' in mnem
--- Comment #6 from ubizjak at gmail dot com 2009-07-23 07:06 ---
(In reply to comment #5)
> The code that confuses gas is in fact ffreep insn. Since your gas is detected
> as not supporting ffreep mnemonic directly, gcc generates it with .word
> 0xc0df.
/s/gcc/sun as/, of course. Whe
--- Comment #7 from ubizjak at gmail dot com 2009-07-23 07:58 ---
We should use ASM_SHORT instead of .word.
I have a patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
Compile the following code with options -Os -mthumb -march=armv5te
int bar();
void goo(int, int);
void foo()
{
int v = bar();
if (v == 0)
return;
goo(1, v);
}
Gcc generates:
push{r3, lr}
bl bar
mov r1, r0
cmp r0, #0// *
beq
--- Comment #1 from carrot at google dot com 2009-07-23 08:38 ---
Created an attachment (id=18241)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18241&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-23 08:47 ---
Can you try with the patch for 40799 applied before gimplification
unit-at-a-time? Does the failure reproduce with the test data or only with the
ref data?
--
rguenth at gcc dot gnu dot org changed:
W
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-23 08:52 ---
Hmm, to early, the gfc_*_intrinsic are not called, unless attr.intrinsic is
set. The but the issue is indeed that they are regarded as PTYPE_SPECIFIC and
not as PTYPE_UNKNOWN, as a printf in resolve_function shows - t
When trying to build an iwmmxt optimized gcc 4.4.1, build fails in libobjc with
an ICE:
In function 'objc_msg_sendv':
error: insn does not satisfy its constraints:
(set (reg/f:SI 13 sp)
(reg/f:SI 43 wcgr0 [146])) 441 {*iwmmxt_movsi_insn} (nil))
internal compiler error: in reload_
--- Comment #1 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-07-23 09:46 ---
Created an attachment (id=18242)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18242&action=view)
gcc cmdline + output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #2 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-07-23 09:47 ---
Created an attachment (id=18243)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18243&action=view)
preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #3 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-07-23 09:48 ---
Created an attachment (id=18244)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18244&action=view)
assembly output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #8 from uros at gcc dot gnu dot org 2009-07-23 09:51 ---
Subject: Bug 40832
Author: uros
Date: Thu Jul 23 09:51:33 2009
New Revision: 149988
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149988
Log:
PR target/40832
* config/i386/i386.c (output_387_ff
--- Comment #9 from uros at gcc dot gnu dot org 2009-07-23 10:22 ---
Subject: Bug 40832
Author: uros
Date: Thu Jul 23 10:22:43 2009
New Revision: 149995
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149995
Log:
PR target/40832
* config/i386/i386.c (output_387_ff
--- Comment #10 from uros at gcc dot gnu dot org 2009-07-23 10:23 ---
Subject: Bug 40832
Author: uros
Date: Thu Jul 23 10:23:43 2009
New Revision: 149996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149996
Log:
PR target/40832
* config/i386/i386.c (output_387_f
--- Comment #11 from ubizjak at gmail dot com 2009-07-23 10:26 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
The following C program should print "369", and return a zero exit status.
It does not work on 64-bit Windows Vista. Instead, it crashes before
the printf, and returns exit status 5. This is, I assume, because
trampolines do not work. I guess the protection bits for stack pages need
to be set to
--- Comment #2 from david dot sagan at gmail dot com 2009-07-23 10:59
---
The commands show:
lnx498:/nfs/acc/temp/dcs/gcc/gcc_tmp> find /usr -name gmp.h
/usr/include/gmp.h
find: /usr/share/ssl/CA: Permission denied
[1] + Done emacs -g 100x80 ~/.chsrc
lnx498:/n
--- Comment #1 from sezeroz at gmail dot com 2009-07-23 11:10 ---
Curious. As a data point, can't reproduce this with 4.4 (svn rev.149965).
--
sezeroz at gmail dot com changed:
What|Removed |Added
--
--- Comment #15 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 11:12 ---
The patch just walks around the problem and doesn't really fix it. It is simply
a hack that disables frame generation for long long, while for the other types
the same problem persists:
Exampl
--- Comment #1 from matz at gcc dot gnu dot org 2009-07-23 11:16 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #16 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 11:18 ---
In the above example, the output of assembler is:
f:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
fldl8(%ebp)
fstpl (%esp)
callg
--- Comment #17 from jakub at gcc dot gnu dot org 2009-07-23 11:36 ---
Incorrect? Why do you think so?
double on ix86 has 8 byte alignment, and unlike long long it has also
performance effects when you misalign it (in theory, we could handle double the
same as long long with -Os though)
--- Comment #2 from matz at gcc dot gnu dot org 2009-07-23 12:03 ---
Subject: Bug 40830
Author: matz
Date: Thu Jul 23 12:02:37 2009
New Revision: 14
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=14
Log:
PR middle-end/40830
* gcc.dg/vect/vect-pre-interact
--- Comment #3 from matz at gcc dot gnu dot org 2009-07-23 12:05 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #18 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 12:16 ---
The bug is this: you don't align the stack and you generate the frame. Why?
Why don't you do one of these?:
* generate the frame and align
* don't generate the frame and don't align
these two
--- Comment #2 from charlet at gcc dot gnu dot org 2009-07-23 12:20 ---
Are you using a 64 bit compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40837
--- Comment #19 from jakub at gcc dot gnu dot org 2009-07-23 12:33 ---
Because you need to decide whether to use a frame pointer or not before
register allocation, and only during/after register allocation you can find out
that something needs to be spilled to stack.
--
http://gcc.g
--- Comment #33 from krebbel at gcc dot gnu dot org 2009-07-23 12:37
---
Your patch from 2009-06-30 prevents the following code from being implemented
jumpless on S/390:
int a, b;
...
int x = a == b;
In emit_store_flag the following code now invokes emit_store_flag_1 instead of
emit_s
--- Comment #3 from sezeroz at gmail dot com 2009-07-23 12:40 ---
I cross-compile from i686-linux to x86_64-pc-mingw32. (I can also try
cross-compiling from x86_64-linux to x86_64-pc-mingw32, if you want.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40837
typedef int v4si __attribute__ ((vector_size (16)));
v4si y(v4si *s3)
{
return *s3;
}
extern v4si s1, s2;
v4si x(void)
{
v4si s3 = s1 + s2;
return y(&s3);
}
And compile it with -O2 -fno-inline -msse2 -fomit-frame-pointer
The variable s3 is stored using unaligned store (
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-23 12:56 ---
Linux/ix86 ABI says that stack must be 16 byte aligned. So GCC can rely on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #4 from charlet at gcc dot gnu dot org 2009-07-23 13:10 ---
Interesting, thanks for the feedback. Let me double check a few things on
my side (testing various GCC versions).
Arno
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40837
--- Comment #22 from jakub at gcc dot gnu dot org 2009-07-23 13:13 ---
*** Bug 40838 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-23 13:13 ---
*** This bug has been marked as a duplicate of 38496 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 13:15 ---
What I would propose to fix this and bug #40667:
Each type has required alignment and preferred alignment. Enforced alignment is
what is needed to not crash and not violate the ABI, preferred a
--- Comment #4 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 13:19 ---
"Linux/ix86 ABI says that stack must be 16 byte aligned."
No it doesn't. There is a plenty of Linux code that doesn't have the stack
aligned on 16-byte boundary. (at least anything that was com
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-23 13:24 ---
The ABI has changed 8+ years ago, you are coming too late.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #20 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 13:28 ---
I see, if it gets spilled to the stack as a local variable, it realigns the
stack, if it doesn't get spilled, it doesn't. But shouldn't "passing the
variable as an argument on the stack" be tre
--- Comment #23 from jakub at gcc dot gnu dot org 2009-07-23 13:36 ---
Can you please
grep xmake_file= gcc/Makefile
in the gcc build directory as well as write what
gcc -Wl,--version
prints? Binutils 2.19 and later have the needed relax fixes I think, so
rs6000/x-linux-relax should be u
--- Comment #6 from hjl dot tools at gmail dot com 2009-07-23 13:43 ---
*** This bug has been marked as a duplicate of 39315 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #11 from hjl dot tools at gmail dot com 2009-07-23 13:43
---
*** Bug 40838 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #5 from sezeroz at gmail dot com 2009-07-23 13:46 ---
Compiled my same toolchain on linux-x86_64 and compiled the test for
x86_64-pc-mingw32, the resulting exe prints 369 on Vista-SP2-x64 and exits
normally.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40837
--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 13:49 ---
See bug #27537, quoting "GNU/Linux follows the SYSV x86 ABI which is
documented, maybe you cannot find it but it does exist. The SYSV x86 ABI says
the stack is aligned 4 byte aligned."
That bug
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-23 13:54 ---
Please read Joseph's responses in PR38496.
If you are aware of places in glibc that don't maintain 16 byte stack
alignment, please report them. Certainly calling glibc (or any other default
compiler flags compiled) l
--- Comment #9 from hjl dot tools at gmail dot com 2009-07-23 13:56 ---
(In reply to comment #7)
>
> Another point: if gcc realigns the stack, why then use movdqu to store the
> values on the stack? That is suboptimal.
>
This is a dup for PR 39315.
--
http://gcc.gnu.org/bugzilla/
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-23 14:06
---
The code is invalid. This is allowed:
template <>
template
class Outer::Inner {};
but not the other way around. The diagnostic is correct to say "enclosing
class templates are not explicitly specialized"
See
--- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 14:34 ---
So, Joseph is basically arguing that it doesn't make sense to follow bad
standards. Fine. So let's ignore the "i386 ABI standard" thing for a moment a
look at the change from the practical poin
--- Comment #10 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 14:36 ---
Jakub: so try that "test $15, %esp; jnz abort" at every function, as I proposed
in bug #38496. There are much more places that will trigger this. Just go catch
them.
--
http://gcc.gnu.org/
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-23 14:38 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-23 14:40 ---
(In reply to comment #1)
> Can you try with the patch for 40799 applied before gimplification
> unit-at-a-time? Does the failure reproduce with the test data or only with the
> ref data?
>
I applied the patch for P
--- Comment #3 from kargl at gcc dot gnu dot org 2009-07-23 14:55 ---
(In reply to comment #2)
> The commands show:
>
> lnx498:/nfs/acc/temp/dcs/gcc/gcc_tmp> find /usr -name gmp.h
> /usr/include/gmp.h
> find: /usr/share/ssl/CA: Permission denied
> [1] + Done em
--- Comment #6 from charlet at gcc dot gnu dot org 2009-07-23 15:02 ---
My confusion: I thought I had tested with GCC 4.5 but in fact I had used
GCC 4.3 which does not have the 'MINGW_ENABLE_EXECUTE_STACK' macro (and
__enable_execute_stack symbol).
Arno
--
charlet at gcc dot gnu dot
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-23 15:06
---
Thanks Jon.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from rguenther at suse dot de 2009-07-23 15:21 ---
Subject: Re: [4.5 Regression] Revision 149750 failed
483.xalancbmk in SPEC CPU 2006
On Thu, 23 Jul 2009, hjl dot tools at gmail dot com wrote:
> --- Comment #2 from hjl dot tools at gmail dot com 2009-07-23 14:40
--- Comment #4 from david dot sagan at gmail dot com 2009-07-23 15:32
---
> It has nothing to do with the version number. Read the log file you
> included in your original post. You'll find
Thanks for the information. As I see it, the problem here is that the error
message from confi
Compiling this code with gfortran (4.3.2 and 4.3.3, Linux and Solaris) produces
a segmentation fault in gfortran (internal error):
write(fmt='(''STRING'')')
end
Compile command: gfortran FilecontainingCode.f
Message:
f951: internal compiler error: Segmentation fault
Please submit a
--- Comment #15 from manu at gcc dot gnu dot org 2009-07-23 15:35 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01179.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from wirawan0 at gmail dot com 2009-07-23 16:03 ---
Sorry for my confusion. It turned out that the option -Wno-unused-parameter (no
s) did work on 4.3.2. Marking this bug as invalid.
--
wirawan0 at gmail dot com changed:
What|Removed
--- Comment #4 from hubicka at ucw dot cz 2009-07-23 16:15 ---
Subject: Re: [4.5 Regression] segfault in useless_type_conversion_p
Hi,
the problem here is in removing virtual PHI. We replace uses of the
virtual PHI results by the corresponding VAR_DECL and send symbol for
renaming. H
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-23 16:29 ---
Created an attachment (id=18245)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18245&action=view)
gcc45-pr40839.patch
Patch I'm going to test.
--
jakub at gcc dot gnu dot org changed:
What|Re
--- Comment #3 from andhow at gmail dot com 2009-07-23 16:31 ---
That is very strange indeed; sorry for the mistake!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40828
--- Comment #24 from giffordj at la dot twcbc dot com 2009-07-23 16:50
---
root:/var/build_system/work/gcc-build# grep xmake_file= gcc/Makefile
xmake_file= $(srcdir)/config/rs6000/x-rs6000
$(srcdir)/config/rs6000/x-linux-relax $(srcdir)/config/x-linux
root:/var/build_system$ gcc -Wl,--
--- Comment #25 from jakub at gcc dot gnu dot org 2009-07-23 16:56 ---
Is -Wl,--relax passed to the compiler driver when linking the binary that fails
to link then? If yes, you are looking at a ld problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
--- Comment #3 from da_cra_hunt at yahoo dot com 2009-07-23 17:34 ---
Simple case :
template struct A {};
template struct B { struct Inner {}; };
template
struct A::Inner> {};
4.1.2/VS2005 compile quietly. 4.3.2 (g++ -c test.cpp) gives :
kk.cpp:5: error: template parameters not use
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40684
--- Comment #10 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40799
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-
--- Comment #8 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40705
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-0
--- Comment #5 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40753
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-0
--- Comment #8 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40357
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-0
--- Comment #7 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40662
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-0
--- Comment #38 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40330
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-
--- Comment #6 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40496
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-0
--- Comment #4 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40692
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-0
--- Comment #9 from hjl at gcc dot gnu dot org 2009-07-23 17:51 ---
Subject: Bug 40676
Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23 H.J. Lu
Backport from mainline:
2009-0
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-23 18:09 ---
Subject: Bug 40839
Author: jakub
Date: Thu Jul 23 18:09:43 2009
New Revision: 150021
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150021
Log:
PR fortran/40839
* io.c (gfc_resolve_dt): Add LOC
--- Comment #4 from hjl dot tools at gmail dot com 2009-07-23 18:15 ---
FunctionSubstringAfter.cpp FunctionSubstringBefore.cpp FunctionSubstring.cpp
are miscompiled. I have to replace all of them to get a working binary,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834
--- Comment #5 from hjl dot tools at gmail dot com 2009-07-23 18:19 ---
(In reply to comment #4)
> FunctionSubstringAfter.cpp FunctionSubstringBefore.cpp FunctionSubstring.cpp
> are miscompiled. I have to replace all of them to get a working binary,
>
It fails even with -O0. Replace
--- Comment #26 from giffordj at la dot twcbc dot com 2009-07-23 18:36
---
Looks like it's being used. Any ideas?
gcc -isystem /usr/include -m32 -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition
--- Comment #6 from hjl dot tools at gmail dot com 2009-07-23 18:48 ---
Created an attachment (id=18246)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18246&action=view)
A testcase
You can compare the outputs before and after change.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #7 from hjl dot tools at gmail dot com 2009-07-23 18:56 ---
Here are the differences between good and bad
GOOD const struct XalanDOMString & theFirstString = (const struct
XalanDOMString &) (const struct XalanDOMString *) OBJ_TYPE_REF(*(SAVE_EXPR
(&arg1)>->D.20005._vptr.Xal
--- Comment #8 from hjl dot tools at gmail dot com 2009-07-23 18:57 ---
Jason, can you take a look at this?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2009-07-23 19:16 ---
This patch:
Index: cp-gimplify.c
===
--- cp-gimplify.c (revision 149933)
+++ cp-gimplify.c (working copy)
@@ -804,15 +804,6 @@ cp_genericiz
As you suggested, I downloaded/built bison 1.875 (plus the latest m4)
and got passed the problem below. However, there is a new problem. File
config.cache in the gcc directory is empty and no Makefile was
generated. Consequently, the following error occurs:
make[3]: Entering directory
`/home/user
spu-g++ -v
Using built-in specs.
Target: spu
Configured with: ../toolchain/gcc/configure --prefix=/opt/cell/toolchain
--mandir=/opt/cell/toolchain/man --infodir=/opt/cell/toolchain/info
--with-sysroot=/opt/cell/sysroot --disable-shared --disable-threads
--disable-checking --with-headers --with-sys
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-23 20:14 ---
Fixed in 4.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #2 from doubletwist at fearthepenguin dot net 2009-07-23 20:21
---
I see the exact same error on Solaris 8 Sparc using GCC 4.3.2
--
doubletwist at fearthepenguin dot net changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-23 20:24 ---
This error is correct as we have:
register int overflow __asm__("%g6");
...
__asm__ ( "addcc %2,%3,%0; addx %%g0,%%g0,%1" : "=r" (__value), "=r"
(overflow) : "r" (__arg1), "r" (__arg2) : "%g6","cc");
So t
I configure the fstream like this:
ifstream is;
is.exceptions(ifstream::badbit | ifstream::failbit);
is.open(filename, ifstream::in | ifstream::binary);
When it tries to open a file that does not exist, it throws an exception just
as it should. If this is immediately inside a try/cat
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-23 20:46
---
First of all, please provide a complete, small, self contained, snippet showing
the problem. Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #2 from zlynx at acm dot org 2009-07-23 21:01 ---
Created an attachment (id=18247)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18247&action=view)
reproduce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40841
--- Comment #3 from zlynx at acm dot org 2009-07-23 21:03 ---
Also note that this seems to be a IA64 problem, not x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40841
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-23 21:09
---
I see, I can't reproduce it on x86_64-linux, maybe Richard can help for ia64
testing... If that's really the case, however, probably not a libstdc++-proper
issue.
--
paolo dot carlini at oracle dot com chan
Moving this issue from bz 39976 since it is a separate problem than the
original documented there.
Verified the behavior still exists using current trunk revision (150020). The
testcase comes from cpu2000 sixtrack benchmark. Following is original comment I
posted:
===
The attatched testcase
--- Comment #1 from pthaugen at gcc dot gnu dot org 2009-07-23 21:33
---
Created an attachment (id=18248)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18248&action=view)
Testcase
The reduced testcase (since you can't attatch one when opening a new bz).
--
http://gcc.gnu.org
// Illegal access to private member not detected, program compiles silently.
// bug found in:
// g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
// g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3
#include
class A {
enum { value=1 }; // private
};
template // bug appears only if B is a template
struc
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-23 21:46 ---
I think this is a duplicate of bug 21008.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #17 from drow at gcc dot gnu dot org 2009-07-23 21:50 ---
Steven, have you had time for this? Anything we can do to help?
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from sipych at gmail dot com 2009-07-23 22:08 ---
(In reply to comment #1)
> I think this is a duplicate of bug 21008.
>
Not shure, A::value may not be accessible neither at the template definition,
nor at the instantiation time.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #18 from stevenb dot gcc at gmail dot com 2009-07-23 22:23
---
Subject: Re: [4.3/4.4/4.5 Regression] huge
performance regression on EEMBC bitmnp01
I had the patch ready but Matz' PRE patch means I have to rework things a bit.
Since I only have time for this in wee
--- Comment #5 from zlynx at acm dot org 2009-07-23 22:26 ---
The actual segfault seems to happen in the .plt section. I am not entirely
clear on how this is laid out and how to find what symbol is where.
But on entry to the plt code, the r1 register is set to an invalid memory
location
1 - 100 of 120 matches
Mail list logo
