--- 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 t
--- 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
--- 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 insu
--- 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 ha
--- 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=20304&action=view)
Precompiled source
g++ -O3 -march=amdfam10 -std=gnu++0x graph.i
generates the internal compiler error
--
http:/
--- 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=20305&action=view)
reduced version of 157942-emutls-finalize-diff.txt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- 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 c
--- 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 wri
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-04 17:17 ---
reduced
#include
using namespace std;
struct Row { };
void drawInside( )
{
auto lambda =
[ ] ( const Row* curRow ) -> pair
{
return std::pair( );
};
}
--
http://gcc.gnu.org/bugzilla/show_b
--- 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 re
--- 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...
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00318
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 floatin
--- 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 re-c
--- 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
--- 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
#i
--- 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=20306&action=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>:ad
--- 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
34 matches
Mail list logo
