--- Comment #4 from steven at gcc dot gnu dot org 2009-07-24 06:27 ---
A hint, please, about why the patch of comment #2 would be the correct fix. As
far as I can tell, loop-iv doesn't need the notes and shouldn't have to clean
up other passes' mess. This patch also introduces a pass or
--- Comment #3 from ubizjak at gmail dot com 2009-07-24 06:25 ---
Please also add the testcase from Comment #1 to gcc testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
--- Comment #1 from pinskia at gmail dot com 2009-07-24 05:54 ---
Subject: Re: New: O2 optimizes out assignment to bitfield
Sent from my iPhone
On Jul 23, 2009, at 10:22 PM, "jim at bodwin dot us" wrote:
> Incorrect code is produced for the following source with the O2
> option
Sent from my iPhone
On Jul 23, 2009, at 10:22 PM, "jim at bodwin dot us" > wrote:
Incorrect code is produced for the following source with the O2
option. In
particular, the assignment to the bitfield field2 is optimized out
of the code
entirely and regImage is left all zero. Correct cod
--- Comment #35 from jv244 at cam dot ac dot uk 2009-07-24 05:48 ---
(In reply to comment #34)
> I won't be able to reduce this failure for the next 10 days or so.
as a PS, the multiple-file compilation of trunk cp2k goes fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #34 from jv244 at cam dot ac dot uk 2009-07-24 05:39 ---
Testing paul's latest patch at
http://gcc.gnu.org/ml/fortran/2009-07/msg00202.html
on the latest all file CP2K (see also PR40005)
http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2009-05-01.f90.gz
I get the following I
Incorrect code is produced for the following source with the O2 option. In
particular, the assignment to the bitfield field2 is optimized out of the code
entirely and regImage is left all zero. Correct code is produced with the O1
option and (at least) with gcc version 4.3.2.
===
--- Comment #2 from ian at gcc dot gnu dot org 2009-07-24 04:01 ---
Subject: Bug 40209
Author: ian
Date: Fri Jul 24 04:01:13 2009
New Revision: 150038
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150038
Log:
PR rtl-optimization/40209
* loop-iv.c (iv_analysis_lo
--- Comment #2 from carrot at google dot com 2009-07-24 02:11 ---
It seems HAVE_cc0 disabled for arm. What's the reason behind it?
A simple method is to add a peephole rule to handle it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835
--- Comment #6 from hjl dot tools at gmail dot com 2009-07-24 01:52 ---
It works for me on RHEL 4 with gcc 4.4.1:
[...@gnu-14 tmp]$ cat foo.cc
#include
using namespace std;
void f(const char * filename)
{
ifstream is;
throw 2;
}
int main()
{
try {
f("v3");
} catch(int e) {
}
--- Comment #3 from bje at gcc dot gnu dot org 2009-07-24 00:42 ---
I checked in Ryan's patch for him.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-24 00:42 ---
Subject: Bug 40429
Author: bje
Date: Fri Jul 24 00:41:54 2009
New Revision: 150037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150037
Log:
2009-06-13 Ryan Mansfield
PR lto/40429
* lto-wrap
--- Comment #5 from kargl at gcc dot gnu dot org 2009-07-24 00:31 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from kargl at gcc dot gnu dot org 2009-07-24 00:28 ---
Subject: Bug 40727
Author: kargl
Date: Fri Jul 24 00:28:43 2009
New Revision: 150036
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150036
Log:
2009-07-23 Steven G. Kargl
PR fortran/40727
*
--- Comment #4 from sipych at gmail dot com 2009-07-24 00:00 ---
// More similar cases. Static members also may be accessed
#include
class A {
enum { value=1 }; // private
static const int ci=2;
static int fi() { return 3; }
};
template // bug appears only if B is a tem
--- Comment #23 from pthaugen at gcc dot gnu dot org 2009-07-23 23:48
---
I opened a new bugzilla, 40482, for the Load-hit-store RA issue discussed in
comments 17-20 since that's a separate problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #36 from bonzini at gnu dot org 2009-07-23 23:01 ---
No, all patches were committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #35 from meissner at linux dot vnet dot ibm dot com 2009-07-23
23:00 ---
Subject: Re: Powerpc bootstrap is broken due to changes in expmed.c
On Thu, Jul 23, 2009 at 10:52:01PM -, paolo dot bonzini at gmail dot com
wrote:
>
>
> --- Comment #34 from paolo dot bonzi
--- Comment #34 from paolo dot bonzini at gmail dot com 2009-07-23 22:52
---
Subject: Re: Powerpc bootstrap is broken due to changes
in expmed.c
On 07/23/2009 02:37 PM, krebbel at gcc dot gnu dot org wrote:
> In emit_store_flag the following code now invokes emit_store_flag_1 instead
--- Comment #3 from sipych at gmail dot com 2009-07-23 22:46 ---
Also present in gcc 4.4.0
--
sipych at gmail dot com changed:
What|Removed |Added
Known to fail|
--- 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
--- 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 #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 #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 #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
---
// 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 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
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 #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
--- 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 #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 #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
-
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 #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
--- 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 #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|
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
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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-
--
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 #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
--- 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 #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 #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 #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 #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 #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 #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
---
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 120 matches
Mail list logo
