>From revision 144119:
struct _Impl_base
{
_Impl_base() = default;
#if 1
~_Impl_base() = default;
#else
~_Impl_base() { }
#endif
};
_Impl_base::~_Impl_base() { }
int main()
{
_Impl_base i;
return 0;
}
compiled:
%COMP.sh "-std=c++0x -g -O2 -Wall -Wextra" default2.cc
Has no error, whe
--- Comment #4 from corinl at gmx dot de 2009-02-12 07:37 ---
here's the copy from the precompiled header file (.ii), may be it helps:
(check_permissions_local removed, it was just for test..same error as before)
uid_t fs_perms_uid_orig; gid_t fs_perms_gid_orig; if (check_permissions)
--- Comment #3 from corinl at gmx dot de 2009-02-12 07:26 ---
Thanks for the info. Unluckily I just found the bug reported first now for
sure:
Code:
// setuid/setgid only affect the current thread
#define FS_PERMS_SET(_uid, _gid) \
bool check_permissions_local = check_permissio
--- Comment #1 from gyunaev at ulduzsoft dot com 2009-02-12 04:19 ---
Created an attachment (id=17284)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17284&action=view)
test.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39163
This is basically a copy of bug report from
http://www.dribin.org/dave/blog/archives/2006/12/05/missing_third_param/
Using the following sample file saved as test.c:
#include
#define NOINLINE __attribute__((noinline))
--- Comment #1 from dougkwan at google dot com 2009-02-12 03:04 ---
I have a test case now. The toolchain is built with gcc trunk, binutils-2.18,
gdb-6.71 and newlib-1.16.0 for target arm-eabi
---
#include
extern int sprintf (char *, const char*, ...);
int
main (void)
{
char buf[10
--- Comment #5 from tydeman at tybor dot com 2009-02-12 02:54 ---
The latest version of TR 18037 is WG14 document N1275 of 2007/10/01.
The suffix really is case insensitive, so 'uhk' has 8 variations.
'll' and 'LL' are not valid suffixes for fixed point constants.
--
http://gcc.gnu.
--- Comment #9 from Joey dot ye at intel dot com 2009-02-12 02:40 ---
(In reply to comment #8)
> We still have push and mov. I guess it may be the best we can do.
I believe so too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-12 02:37 ---
(In reply to comment #6)
> So simply enable ACCUMULATE_OUTGOING_ARGS for stack realign isn't be the best
> option for all cases either.
>
OK. I am closing as WONTFIX.
--
hjl dot tools at gmail dot com changed:
--- Comment #8 from hjl dot tools at gmail dot com 2009-02-12 02:33 ---
(In reply to comment #7)
> Created an attachment (id=17283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17283&action=view) [edit]
> A patch to fix this problem
>
> Impact to other test unknown. Test undergoi
--- Comment #6 from Joey dot ye at intel dot com 2009-02-12 02:33 ---
(In reply to comment #5)
> If ACCUMULATE_OUTGOING_ARGS is off, ECX will be used
> for stack alignment and it may lead to code size
> increase due to register spill since ia32 has very
> few registers.
The code increase
--- Comment #7 from Joey dot ye at intel dot com 2009-02-12 02:26 ---
Created an attachment (id=17283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17283&action=view)
A patch to fix this problem
Impact to other test unknown. Test undergoing.
HJ, can you also help to verify and t
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-12 02:14 ---
I think we should make it an error instead.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #3 from jason at gcc dot gnu dot org 2009-02-12 02:12 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
bash-3.2$ cat /tmp/x.i
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
__m256i
bar (__m256i x)
{
return x;
}
bash-3.2$ gcc -S /tmp/x.i
This is due to type_natural_mode doesn't check 32byte types. If I
add
--- ./i386.c.warn 2009-02-11 06:58:52.0 -
I am building gcc 4.4.0 20090210 [trunk revision 144083] on OpenSolaris 2009.06
.
The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.
# isainfo -k
amd64
# uname -a
SunOS opensolaris 5.11 snv_106 i86pc i386 i86pc
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-12 02:01 ---
Subject: Bug 39153
Author: jason
Date: Thu Feb 12 02:01:07 2009
New Revision: 144119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144119
Log:
PR c++/39153
* decl2.c (cp_write_global_declarati
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-12 01:58 ---
locate_and_pad_parm in function.c has
/* Remember if the outgoing parameter requires extra alignment on the
calling function side. */
if (crtl->stack_alignment_needed < boundary)
crtl->stack_alignment_
--- Comment #5 from Joey dot ye at intel dot com 2009-02-12 01:45 ---
Stack realign is finalized by
stack_realign = (incoming_stack_boundary
< (current_function_is_leaf
? crtl->max_used_stack_slot_alignment
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-12 01:38 ---
(In reply to comment #4)
> The problem is that inside mems we use MULT not ASHIFT.
>
> Can you please test this? Thanks!
>
> --- config/i386/i386.md (revision 144098)
> +++ config/i386/i386.md (working copy)
> @@ -
--- Comment #1 from wilsons at start dot ca 2009-02-12 00:56 ---
Created an attachment (id=17282)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17282&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39160
Note that the test code is not semantically correct. Correct code compiles
just fine. For me, the bug manifests in both 4.3.2 and the 4.4-20090206
snapshot.
Configure options:
--disable-multilib --enable-languages=c,ada
System type:
$ uname -ro
2.6.27.12-170.2.5.fc10.x86_64 GNU/Linux
Outp
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-12 00:44 ---
I tried -maccumulate-outgoing-args on 2.6 kernel:
textdata bss dec hex filename
5136786 600084 1003520 6740390 66d9a6 vmlinux
5086759 600084 1003520 6690363 66163b /tmp/vmlinux.old
It does in
--- Comment #24 from manu at gcc dot gnu dot org 2009-02-12 00:25 ---
Is there anything that remains to be done here?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-11 23:59 ---
The dynamic stack alignment may not be easy to optimize out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
gcc 4.3 issues a warning for the declaration of struct A below despite the
attribute on the declaration being consistent with that on the definition and
thus benign. While the warning is valuable in cases where the attributes
between the declaration and the definition do not match, it is not useful
--- Comment #3 from jsworley at qwest dot net 2009-02-11 23:41 ---
Accepting Steve Ellcey's analysis, it would seem that the tail call *should* be
recognized when -mconstant-gp is specified; however, it isn't.
--
jsworley at qwest dot net changed:
What|Removed
--- Comment #4 from jason at gcc dot gnu dot org 2009-02-11 23:04 ---
Fixed for 4.3 as well.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #3 from manu at gcc dot gnu dot org 2009-02-11 23:04 ---
Confirmed. I have a patch for this for 4.5.
The new wording will say:
warning: logical 'or' applied to non-boolean constant.
Are you satisfied with this?
>
> BTW, why no warning for this?
>resp == 0 && 0
> Natu
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-11 22:50 ---
Fixed for 4.4.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-11 22:38 ---
Subject: Bug 30111
Author: jason
Date: Wed Feb 11 22:38:37 2009
New Revision: 144112
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144112
Log:
PR c++/30111
* init.c (build_value_init_noctor):
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-02-11 22:13 ---
Whoops, wrong state in browser
*** This bug has been marked as a duplicate of 39153 ***
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-02-11 22:13 ---
*** Bug 39158 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-11 22:13 ---
We need a reproducible preprocessed testcase.
See http://gcc.gnu.org/bugs.html#detailed
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
Compiling:
struct _Impl_base
{
_Impl_base() = default;
virtual ~_Impl_base() = default;
};
template
class _Impl : public _Impl_base
{ };
int main()
{
_Impl i;
return 0;
}
Gives:
gcc version 4.4.0 20090208 (experimental) (GCC)
%COMP.sh "-g -O0 -std=c++0x -fno-inline" vague_vs_default.
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-02-11 22:11
---
Is there a reason why this is a P1? I don't see why this should be a P1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
BugsThisDependsOn|
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-11 22:02 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-11 21:58 ---
Subject: Bug 39154
Author: jakub
Date: Wed Feb 11 21:57:52 2009
New Revision: 144111
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144111
Log:
PR middle-end/39154
* gimplify.c (omp_notice_vari
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
With this compiler
[luc...@descartes gambit]$ gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../../gcc-4.3.3/configure --prefix=/pkgs/gcc-4.3.3
--enable-languages=c --with-cpu=default64
Thread model: posix
gcc version 4.3.3 (GCC)
with the file compiler.i found
--- Comment #6 from dominiq at lps dot ens dot fr 2009-02-11 21:41 ---
With the patch in comment #4 the test in comment #3 compiles without ICE on
i686-apple-darwin9 (it gave an ICE before the patch).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
--- Comment #8 from jason at gcc dot gnu dot org 2009-02-11 21:31 ---
I've reopened PR 28274 with the PR in comment #2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-11 21:31 ---
The extern "C" testcase passed under the 3.2 compiler; marking as regression.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-11 21:28 ---
This is still broken inside extern "C":
extern "C" {
void foo (int i, int j = 6);
void foo (int i = 4, int j);
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from bonzini at gnu dot org 2009-02-11 21:20 ---
There was wrapping, all you have to do is remove "simplify_".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
--- Comment #4 from bonzini at gnu dot org 2009-02-11 21:20 ---
The problem is that inside mems we use MULT not ASHIFT.
Can you please test this? Thanks!
--- config/i386/i386.md (revision 144098)
+++ config/i386/i386.md (working copy)
@@ -20722,7 +20722,7 @@
(parallel [(set (match_
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 21:12 ---
You reported this against 4.0.1 and 4.0.x and 4.1.x are no longer being
supported (meaning no more 4.0.x or 4.1.x release). Since it has been fixed in
4.1.2, I am closing this as fixed.
--
pinskia at gcc dot gnu
This line of code causes an internal compiler when compiled with g++ without
options:
class B;template void foo(B& x) {x(0);}
Compiler:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure
--prefix=/usr/local/compilers/gcc-4.0.1-x86_64-x86_64 --enable-la
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 21:08 ---
You reported this against 4.0.1 and 4.0.x and 4.1.x are no longer being
supported (meaning no more 4.0.x or 4.1.x release). Since it has been fixed in
4.1.2, I am closing this as fixed.
--
pinskia at gcc dot gnu
The following code causes an internal compiler error when compiled with g++
without options:
namespace N{template void foo();}
using namespace N;
template void foo(){}
template void foo();
Compiler info:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configu
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-11 20:59 ---
A testcase:
[...@gnu-27 Docs]$ cat /tmp/x.f
SUBROUTINE CASHES(E,HESS,FC,FA,NORB,NPR)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
PARAMETER (MXAO=2047)
DIMENSION HESS(NPR),E(NORB,*),FC(*),FA(*)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 20:56 ---
How is this major, this is an enhancement to the build system. i386-solaris is
a multi arch target so it includes the x86_64 solaris target also.
--
pinskia at gcc dot gnu dot org changed:
What|R
--- Comment #1 from rob1weld at aol dot com 2009-02-11 20:54 ---
A workaround is to ./configure using "--without-ppl" which will cause
"ppllibs" to create an empty variable in the Makefiles. The output from
the initial configuring will look the same, but this Bug will be avoided.
I'm go
--- Comment #2 from bonzini at gnu dot org 2009-02-11 20:48 ---
Why is this unrecognizable?!? ebx can be an index as well as the base.
Anyway, easily fixed. Will post a patch tomorrow.
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-11 20:24 ---
Revision 144098:
http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00264.html
is the cause. Joey, Xuepeng, can you find a small testcase?
--
hjl dot tools at gmail dot com changed:
What|Removed
The following testcase segfaults at runtime or ICEs (with checking compiler):
extern void abort (void);
int n = 20;
int
main ()
{
int a[n], b[n][n];
#pragma omp parallel for
for (int i = 0; i < n; i++)
{
a[i] = i + 1;
#pragma omp parallel for
for (int j = 0; j < n; j++)
b[i][j] =
Compiling:
struct _Impl_base
{
_Impl_base() = default;
virtual ~_Impl_base() = default;
};
template
class _Impl : public _Impl_base
{ };
int main()
{
_Impl i;
return 0;
}
Gives:
gcc version 4.4.0 20090208 (experimental) (GCC)
%COMP.sh "-g -O0 -std=c++0x -fno-inline" vague_vs_default.
--- Comment #13 from jv244 at cam dot ac dot uk 2009-02-11 19:25 ---
(In reply to comment #12)
> /* For -O2 and beyond, turn off -fschedule-insns by default. It tends to
> make the problem with not enough registers even worse. */
>
> As risky as this may be (for performance, no
--- Comment #2 from sje at cup dot hp dot com 2009-02-11 19:04 ---
This behaviour changed with the patch to fix PR 10907 and I believe that GCC is
correct in not doing the tail call optimization. The optimization is not done
because ia64_function_ok_for_sibcall returns false and it retu
--- Comment #36 from bugzilla-gcc at thewrittenword dot com 2009-02-11
19:03 ---
(In reply to comment #26)
> > We have filed case #65952072 with Sun to get this backported to Solaris 10.
>
> Do you have any news about this?
Sun just released patch 139574-03 for SPARC and 139575-03 for
On Linux/ia32, revision 144101 gave:
gfortran -m32 -c -o mccas.fppized.o-O2 -ffast-math -mfpmath=sse -mssse3
-ffixed-form mccas.fppized.f
mccas.fppized.f: In function 'cashes':
mccas.fppized.f:1745: error: unrecognizable insn:
(insn 364 296 365 5 mccas.fppized.f:1712 (set (reg/v:
--- Comment #12 from bonzini at gnu dot org 2009-02-11 19:00 ---
/* For -O2 and beyond, turn off -fschedule-insns by default. It tends to
make the problem with not enough registers even worse. */
As risky as this may be (for performance, not correctness), what about changing
"i
--- Comment #6 from bonzini at gnu dot org 2009-02-11 18:59 ---
hm if i didn't look at it so far, i guess no. :-( but if i have time i will
look at it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
--- Comment #4 from janis at gcc dot gnu dot org 2009-02-11 18:27 ---
N1169 says that the suffix for a fixed-point literal constant is case
insensitive, which to me means that uhk can be uhK/uHk/uHK/Uhk/UhK/UHk as well
as UHK. It's easier to implement that way, but if it's really suppos
--- Comment #12 from lucier at math dot purdue dot edu 2009-02-11 18:13
---
I just got the same error with
140 12:54 ../../gcc-4.3.3/configure --prefix=/pkgs/gcc-4.3.3
--enable-languages=c
141 12:54 make -j 4 bootstrap > & build.log &
trying to build gcc-4.3.3 with
[luc..
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-11 17:52
---
Paolo, should this be assigned to you?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-11 17:16 ---
(In reply to comment #3)
> If you mean setting ACCUMULATE_OUTGOING_ARGS to true, I bet that could help
Oops. Yes, I meant setting ACCUMULATE_OUTGOING_ARGS to true when stack
alignment is needed.
> very small functi
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-11 17:11 ---
If you mean setting ACCUMULATE_OUTGOING_ARGS to true, I bet that could help
very small functions that need dynamic realignment, but certainly for larger
functions !ACCUMULATE_OUTGOING_ARGS results in smaller code, even
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-11 16:53 ---
Also expand_one_var in cfgexpand.c has
if (crtl->stack_alignment_estimated < align)
{
/* stack_alignment_estimated shouldn't change after stack
realign decision made */
--- Comment #10 from valery_reznic at yahoo dot com 2009-02-11 15:56
---
(In reply to comment #9)
> (In reply to comment #8)
>
> > In the inline assembler I MYSELF put arguments in the places where MY (by
> > the
> > way, written in assembler) function expect to get them.
>
> Then yo
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-11 15:54 ---
One way to fix this is to set ACCUMULATE_OUTGOING_ARGS to false
when we need stack alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
--- Comment #6 from burnus at gcc dot gnu dot org 2009-02-11 15:36 ---
See: http://www.j3-fortran.org/doc/meeting/187/09-006A.txt
and there "NUMBER: F03/0116". One now only needs to carefully read the text to
understand the interpretation.
Additionally, it needs to pass some more review
--- Comment #9 from ubizjak at gmail dot com 2009-02-11 15:32 ---
(In reply to comment #8)
> In the inline assembler I MYSELF put arguments in the places where MY (by the
> way, written in assembler) function expect to get them.
Then you actually don't need a compiler... ;)
> I need n
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-11 15:15 ---
This is caused by assign_parms in function.c:
/* Estimate stack alignment from parameter alignment. */
if (SUPPORTS_STACK_ALIGNMENT)
{
unsigned int align = FUNCTION_ARG_BOUNDARY (data.
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
--- Comment #2 from pault at gcc dot gnu dot org 2009-02-11 15:08 ---
This fixes the bug. I need to look at the passing of Cray pointers in general
because it looks a bit shakey to me.
trans-expr.c:
2626c2626,2637
< if (fsym && fsym->attr.value)
---
> if (fsym
--- Comment #22 from ian at airs dot com 2009-02-11 14:49 ---
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
--- Comment #12 from hjl dot tools at gmail dot com 2009-02-11 14:39
---
(In reply to comment #11)
> (In reply to comment #9)
> > Created an attachment (id=17279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279&action=view) [edit]
> > A patch to add a new -malign-double= optio
--- Comment #8 from valery_reznic at yahoo dot com 2009-02-11 14:26 ---
(In reply to comment #7)
> (In reply to comment #5)
>
> > Any why you say I shouldn't call other function from inside asm ?
>
> See for example [1].
>
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331#c14
>
--- Comment #4 from trick at icculus dot org 2009-02-11 13:38 ---
This also happens when dereferencing void pointers (this is invalid code
though, but I get the same error with the code in the first post):
void foo (void *p)
{
asm("" :: "g" (*p));
}
$ gcc -c foo.c
foo.c: In fun
--- Comment #84 from rguenth at gcc dot gnu dot org 2009-02-11 13:22
---
Btw, for further analyzing it would be nice to have a "smaller" testcase.
Smaller being an order of magnitude less states in ___H__20_all_2e_o1()
(an order of magnitude less label addresses in ___hlbl_tbl).
The so
--- Comment #3 from dominiq at lps dot ens dot fr 2009-02-11 13:16 ---
Fixed on trunk (revision 144043), could the fix be applied on 4.3?
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #21 from ubizjak at gmail dot com 2009-02-11 11:55 ---
Fixed again.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|http://gcc.gnu
--- Comment #20 from uros at gcc dot gnu dot org 2009-02-11 11:53 ---
Subject: Bug 39118
Author: uros
Date: Wed Feb 11 11:53:47 2009
New Revision: 144101
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144101
Log:
PR target/39118
* config/i386/i386.md (UNSPEC_MEMO
--- Comment #19 from uros at gcc dot gnu dot org 2009-02-11 11:43 ---
Subject: Bug 39118
Author: uros
Date: Wed Feb 11 11:43:24 2009
New Revision: 144100
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144100
Log:
PR target/39118
* config/i386/i386.md (UNSPEC_MEMO
--- Comment #18 from jakub at gcc dot gnu dot org 2009-02-11 11:00 ---
Created an attachment (id=17281)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17281&action=view)
gcc44-pr39118.patch
Patch I've bootstrapped/regtested on x86_64-linux.
--
http://gcc.gnu.org/bugzilla/show_
Please ignore my previously sent email below. I see it is a "non bug",
despite the utter insanity behind the rationale for it...
Manfred von Willich
Contractor
RapidM
Fax
E-mail
Web : +27 (12) 349-
: +27 (12) 349-0010
: manfre...@rapidm.com
: www.ra
--- Comment #25 from bonzini at gnu dot org 2009-02-11 08:57 ---
patch committed (the changelog was in gcc-patches :-).
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ubizjak at gmail dot com 2009-02-11 08:42 ---
(In reply to comment #9)
> Created an attachment (id=17279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279&action=view) [edit]
> A patch to add a new -malign-double= option
HJ, there were lots of problems with
--- Comment #17 from ubizjak at gmail dot com 2009-02-11 08:32 ---
Created an attachment (id=17280)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17280&action=view)
Patch
This patch inserts _memory_ blockages at the end of function prologue and at
the beginning of function epilogu
--- Comment #16 from ubizjak at gmail dot com 2009-02-11 08:24 ---
(In reply to comment #13)
> This test case is from Mark Heffernan. When compiling with -O2
> -fno-omit-frame-pointer with gcc 4.3, it shows a red zone violation in the
> epilogue:
>
> movl-160(%rbp), %eax
>
--- Comment #24 from ubizjak at gmail dot com 2009-02-11 08:14 ---
(In reply to comment #23)
> Even though you don't observe the reporter's slowdown from 4.2/4.3 to
> unpatched 4.4, I guess this makes a good case for the patch. Ok for trunk?
OK with a ChangeLog ;)
BTW: Please watch b
--- Comment #23 from bonzini at gnu dot org 2009-02-11 08:01 ---
Subject: Re: [4.4 Regression] performance regression of
sse code from 4.2/4.3
> [xg...@shgcc-9 38824]$ time ./gcc-42.out
> real0m1.991s
>
> [xg...@shgcc-9 38824]$ time ./gcc-44.out
> real0m1.880s
>
> [xg...@sh
94 matches
Mail list logo
