This (slightly nonsensical) reduced test case crashes with an internal compiler
error:
void foo(void)
{
int x;
asm volatile(mov $0,%e0\n :=r (x));
}
$ gcc-4.5 tgcc.c -c -o tgcc.o
tgcc.c: In function 'foo':
tgcc.c:6:1: internal compiler error: in reverse_condition, at jump.c:477
gcc 4.4 compiles the following:
_Complex long double foo(long double p1, long double p2)
{
return p1 + (__extension__ 1.0iF) * p2;
}
gcc-4.4 -O3 tgcc.c -c -o tgcc.o
into
0x +0: fldt 0x8(%rsp)
0x0004 +4: fldt 0x18(%rsp)
0x0008
Sent from my iPhone
On Apr 3, 2010, at 11:21 PM, svfuerst at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
gcc 4.4 compiles the following:
_Complex long double foo(long double p1, long double p2)
{
return p1 + (__extension__ 1.0iF) * p2;
}
gcc-4.4 -O3 tgcc.c -c -o tgcc.o
into
--- Comment #1 from pinskia at gmail dot com 2010-04-04 06:28 ---
Subject: Re: New: Missed optimization with complex long double
Sent from my iPhone
On Apr 3, 2010, at 11:21 PM, svfuerst at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
gcc 4.4 compiles the following:
struct u1
{
float x;
float y;
};
float foo(struct u1 u)
{
return u.x + u.y;
}
compiles into
gcc-4.5 -O3 tgcc.c -c -o tgcc.o
0x +0: movq %xmm0,-0x20(%rsp)
0x0006 +6: mov-0x20(%rsp),%rax
0x000b +11:mov
--- Comment #24 from bonzini at gnu dot org 2010-04-04 07:18 ---
Subject: Re: libgcc built with -DHAVE_CC_TLS against xgcc when
emutls in use
This provides a traverse of the emutls control var htab finalizing
each.
I didn't try to check if vars were already finalized in the
--- Comment #13 from dannysmith at users dot sourceforge dot net
2010-04-04 08:20 ---
(In reply to comment #11)
(In reply to comment #10)
And while the compilation time change alone
How did you configure 4.5? Did you use --enable-checking=release ? If not
then the compile
--- Comment #5 from rwild at gcc dot gnu dot org 2010-04-04 08:40 ---
(In reply to comment #1)
should -c explain how a .mod file is created?
IMHO, the answer is a resounding 'no.' Adding such information
would simply add unneeded clutter to the manual, and should be
an insult to
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2010-04-04
08:47 ---
indeed, my comment #6 is probably wrong for this PR.
(There are a number of m64 structure size fails across the powerpc compiler -
but that issue could well be different from the objc one which also
--- Comment #10 from jb at gcc dot gnu dot org 2010-04-04 10:56 ---
I've been thinking a bit about this issue. Some observations
- There are a lot of compilers, and many ways of representing logicals. Being
compatible with some or all of them is, IMO, a stillborn idea. And even if we'd
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-04-04 15:02
---
That idea of a --clean is interesting. I can see where it would be useful to
force a recompile of module files. I am not sure what the actual flag should
be. Of course one could use make to do all of this.
--
--- Comment #2 from bernard dot van dot duijnen at oracle dot com
2010-04-04 15:08 ---
The message may be unclear, but is in itself correct.
Your function vsnprintf_one needs an annotation because
its first argument is a format string that can be checked itself
to be a valid format. As
--- Comment #2 from drow at gcc dot gnu dot org 2010-04-04 15:45 ---
FYI, this patch also fixes a number of failures in cpexprs.exp in GDB.
Testcase:
struct s
{
bool operator!= (s const o) const { return false; }
};
bool
func (const struct s arg, const struct s right)
{
return
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.5-20100311/configure CFLAGS=' -O3 -march=amdfam10' :
(reconfigured) ../gcc-4.5-20100311/configure CFLAGS=' -O3 -march=amdfam10'
--- Comment #1 from wilhelm at segatz dot org 2010-04-04 16:05 ---
Created an attachment (id=20304)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20304action=view)
Precompiled source
g++ -O3 -march=amdfam10 -std=gnu++0x graph.i
generates the internal compiler error
--
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-04-04
16:30 ---
Created an attachment (id=20305)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20305action=view)
reduced version of 157942-emutls-finalize-diff.txt
--
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2010-04-04
16:33 ---
I can confirm on x86_64-apple-darwin10 that the reduced form of Iain's patch
(reduced_emutis.patch) eliminates all of the profile testcase regressions when
r157822 is reapplied to current gcc trunk. Iain
--- Comment #2 from svfuerst at gmail dot com 2010-04-04 16:51 ---
Paragraph 2 in G.5.1 defines multiplication of a real floating point type by an
imaginary floating point type to be an imaginary type, not a complex type.
In addition, the Rationale for Annex G states that
It allow
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-04 17:17 ---
reduced
#include utility
using namespace std;
struct Row { };
void drawInside( )
{
auto lambda =
[ ] ( const Row* curRow ) - pairint,float
{
return std::pairint,float( );
};
}
--
--- Comment #3 from redi at gcc dot gnu dot org 2010-04-04 17:22 ---
or even just
struct P {};
void drawInside( )
{
[ ] ( ) - P
{
return P();
};
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43641
--- Comment #4 from paolo dot carlini at oracle dot com 2010-04-04 17:44
---
Excellent Jon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43641
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2010-04-04
17:58 ---
Testsuite results for the reduced version of the
157942-emutls-finalize-diff.txt patch and r157822 reapplied to gcc trunk at
r157958 are posted at...
The test c-c++-common/raw-string-1.c fails on ppc (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00315.html or
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00299.html).
I have reduced the failures to any of the following if:
int
main (void)
{
/* if (sizeof (s4) != sizeof (s5)
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-04 18:41 ---
It fails on s390*-linux too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43642
--- Comment #10 from jrgn dot keil at googlemail dot com 2010-04-04 19:02
---
(In reply to comment #6)
I found none of the changes to internal_mcount to be necessary: with the
attached
patch, I could both bootstrap mainline successfully on i386-pc-solaris2.11,
the
-pg related
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-04 19:07 ---
Confirmed. We already expand in this funny way:
;; Generating RTL for gimple basic block 2
;; return D.2720_3;
(insn 6 5 7 t.c:8 (set (reg:SI 65)
(subreg:SI (reg/v:DI 62 [ u ]) 0)) -1 (nil))
(insn 7 6 8
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-04 19:09 ---
Confirmed. 4.3 errors:
gcc-4.3 -S t.c
t.c: In function ?foo?:
t.c:5: error: invalid 'asm': invalid operand code 'e'
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from joseph at codesourcery dot com 2010-04-04 19:12 ---
Subject: Re: Missed optimization with complex long double
On Sun, 4 Apr 2010, svfuerst at gmail dot com wrote:
Paragraph 2 in G.5.1 defines multiplication of a real floating point
type by an imaginary floating
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-04 19:42 ---
Fails on sparc64-unknown-linux-gnu too (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00295.html ).
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #28 from developer at sandoe-acoustics dot co dot uk
2010-04-04 20:18 ---
(In reply to comment #26)
Iain can you post this to gcc-patches with a ChangeLog?
Well, I guess it seems to do the job (I reverted the additional copies in
emutls_decl() on my local branch and
--- Comment #7 from kargl at gcc dot gnu dot org 2010-04-04 20:28 ---
(In reply to comment #5)
(In reply to comment #1)
should -c explain how a .mod file is created?
IMHO, the answer is a resounding 'no.' Adding such information
would simply add unneeded clutter to the
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-04 21:03 ---
Fails on hppa-unknown-linux-gnu too (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00313.html ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43642
When profiling a 64bit binary compiled from the following source,
the resulting binary crashes in strdup() / strlen(),
gcc's 64bit x86 profiling code corrupts the contents of the
%rcx / %rdx register.
% /tmp/gcc4/bin/gcc --version
gcc (GCC) 4.5.0 20100401 (experimental)
% cat test.c
#include
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2010-04-04
21:08 ---
Iain,
Do please post the revised patch to gcc-patches with a changelog. That may
incite a review from the emutls maintainers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
--- Comment #11 from jrgn dot keil at googlemail dot com 2010-04-04 21:09
---
(In reply to comment #10)
I've filed bug 43643 for this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38085
--- Comment #1 from jrgn dot keil at googlemail dot com 2010-04-04 21:15
---
Created an attachment (id=20306)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20306action=view)
SUggested fix
This patch should fix the problem.
% /tmp/gcc4/bin/gcc -m64 -pg -o test test.c
% ./test
__uint128_t foo1(__uint128_t x, __uint128_t y)
{
return x + y;
}
0x0520 +0: mov%rdx,%rax
0x0523 +3: mov%rcx,%rdx
0x0526 +6: push %rbx
0x0527 +7: add%rdi,%rax
0x052a +10:adc
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-04-05 05:06 ---
This appears to have been fixed already. Looking into it.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
39 matches
Mail list logo
