--- 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...@shgcc-9
--- 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
--- 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 #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=17280action=view)
Patch
This patch inserts _memory_ blockages at the end of function prologue and at
the beginning of function
--- 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=17279action=view) [edit]
A patch to add a new -malign-double= option
HJ, there were lots of problems with
--- 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 #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=gccview=revrev=144100
Log:
PR target/39118
* config/i386/i386.md
--- 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=gccview=revrev=144101
Log:
PR target/39118
* config/i386/i386.md
--- Comment #21 from ubizjak at gmail dot com 2009-02-11 11:55 ---
Fixed again.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- 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
--- 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
I read
--- 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=17279action=view) [edit]
A patch to add a new -malign-double= option
--- Comment #22 from ian at airs dot com 2009-02-11 14:49 ---
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
--
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 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
--- 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
--- 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 #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,
--- 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
--- 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 #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
--- 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
--- 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 #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
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
--- 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
--- 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
--- 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, not
Compiling:
struct _Impl_base
{
_Impl_base() = default;
virtual ~_Impl_base() = default;
};
templatetypename _Tp
class _Impl : public _Impl_base
{ };
int main()
{
_Implint i;
return 0;
}
Gives:
gcc version 4.4.0 20090208 (experimental) (GCC)
%COMP.sh -g -O0 -std=c++0x -fno-inline
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] =
--- 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
--- 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 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 going
--- 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
--- 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(*)
The following code causes an internal compiler error when compiled with g++
without options:
namespace N{templateclass T void foo();}
using namespace N;
templateclass T void foo(){}
template void fooint();
Compiler info:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with:
--- 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
This line of code causes an internal compiler when compiled with g++ without
options:
class B;templateclass T 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
--- 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
--- 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
--- 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 #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 #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 #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 #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
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
--
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
--- 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=gccview=revrev=144111
Log:
PR middle-end/39154
* gimplify.c
--- 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
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
BugsThisDependsOn|
--- 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
Compiling:
struct _Impl_base
{
_Impl_base() = default;
virtual ~_Impl_base() = default;
};
templatetypename _Tp
class _Impl : public _Impl_base
{ };
int main()
{
_Implint i;
return 0;
}
Gives:
gcc version 4.4.0 20090208 (experimental) (GCC)
%COMP.sh -g -O0 -std=c++0x -fno-inline
--- 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
--- 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 #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 #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=gccview=revrev=144112
Log:
PR c++/30111
* init.c (build_value_init_noctor):
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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 #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
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
--- 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=17282action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39160
--- 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 #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 #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)
--- 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=gccview=revrev=144119
Log:
PR c++/39153
* decl2.c
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:
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
--- 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
--- 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 #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=17283action=view)
A patch to fix this problem
Impact to other test unknown. Test undergoing.
HJ, can you also help to verify and
--- 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 #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=17283action=view) [edit]
A patch to fix this problem
Impact to other test unknown. Test undergoing.
--- 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 #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 #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.
--
--- 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 stdlib.h
extern int sprintf (char *, const char*, ...);
int
main (void)
{
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 stdio.h
#define NOINLINE
--- 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=17284action=view)
test.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39163
--- 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 =
--- 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)
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, when:
86 matches
Mail list logo
