On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod amacl...@redhat.com wrote:
Richard Guenther wrote:
On Thu, May 6, 2010 at 5:50 PM, Richard Guenther
richard.guent...@gmail.com wrote:
First let me say that the C++ memory model is crap when it
forces data-races to be avoided for unannotated
It is possible. Your expander can handle it before reload; to handle it
during and after reload, you need to implement a TARGET_SECONDARY_RELOAD hook.
http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html#index-TARGET_005fSECONDARY_005fRELOAD-3974
Thanks Dave, It works, but I found
Richard Guenther wrote:
On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod amacl...@redhat.com wrote:
Richard Guenther wrote:
I would have hoped that only data races between independent
objects are covered, thus
tmp = a.i;
b.j = tmp;
would qualify as a load of a and a store to b as far as
On 07/05/2010 12:04, Amker.Cheng wrote:
It is possible. Your expander can handle it before reload; to handle it
during and after reload, you need to implement a TARGET_SECONDARY_RELOAD
hook.
Richard Guenther wrote:
This is a proposal to introduce an optimization level -Ofast
that can collect (target specific) optimization flags that
can affect runtime behavior such as -funsafe-math-optimizations
or -mrecip.
I think that makes sense. Defining what's allowed in these cases is
Hello,
with recent fixes into profile mode I've succeed even using it for
MICO[1] on OpenSolaris platform. It seems only compilation to static
libraries is supported at the moment, but never mind my server run
generates something. As it provides some hints I'd like to more
closely analyze I would
Andrew MacLeod amacl...@redhat.com writes:
They are independent as far as dependencies within this compilation unit.
The problem is if thread number 2 is performing
a.j = val
b.i = val2
now there are data races on both A and B if we load/store full words
and the struct was something
Oops, didn't reply all...
Original Message
Subject:Re: C++0x Memory model and gcc
Date: Fri, 07 May 2010 10:37:40 -0400
From: Andrew MacLeod amacl...@redhat.com
To: Ian Lance Taylor i...@google.com
References: 4be2e39a.5060...@redhat.com
On 05/05/10 21:27, Jeff Law wrote:
On 05/05/10 21:34, Greg McGary wrote:
On 05/05/10 20:21, Jeff Law wrote:
I'm not sure they are ever legitimized -- IIRC caller-save tries to only
generate addressing modes which are safe for precisely this reason.
Apparently not so: caller
On 05/07/10 14:54, Greg McGary wrote:
Unfortunately, that didn't yield any clues. I'll proceed by building
some well-established RISCy target and see what it does in similar
circumstances.
The canonical testcase for caller-save on risc targets was sparc FP code
-- the older sparcs didn't
Hello all,
Essentially, we have code which works fine on x86/PowerPC but fails on ARM due
to differences in how misaligned accesses are handled. The failures occur in
multiple large modules developed outside of our team and we need to find a
solution. The best question to sum this up is, how
-
Workshop on Essential Abstractions in GCC, 2010
(http://www.cse.iitb.ac.in/grc/gcc-workshop-10)
--- Comment #22 from kgardas at objectsecurity dot com 2010-05-07 06:53
---
Viola! Something happens now! Thanks for fixing this.
$ cat test-profile-mode.cc
#include vector
using namespace std;
int main() {
vectorint v;
for (int k = 0; k 1024; ++k) v.insert(v.begin(), k);
}
$
-Wtype-limits should not produce warnings in the following example:
templateclass integer
bool foo(integer x)
{
if(x = 0)
{
// Do something here if integer is positive.
return false;
}
else if(x 0) // Used else if() here instead of
--- Comment #10 from rguenther at suse dot de 2010-05-07 08:39 ---
Subject: Re: PR36320 breaks boost
On Thu, 6 May 2010, knocte at gmail dot com wrote:
--- Comment #9 from knocte at gmail dot com 2010-05-06 18:02 ---
Hello.
I'm in a position in which I cannot upgrade my
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-07 08:43 ---
The problem has been fixed on the LTO side. The Frontend issues remain but
are tracked in PR40976.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-05-07 08:49
---
this seems like a good candidate for using template specialisation to alter the
behaviour
I think the warning is still useful for templates, since it warns you of a
potential mistake in your logic. It doesn't
--- Comment #10 from burnus at gcc dot gnu dot org 2010-05-07 09:16 ---
Created an attachment (id=20592)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20592action=view)
Third draft patch
Updated patch: Support structure constructor if no generic function matches,
function
--- Comment #11 from burnus at gcc dot gnu dot org 2010-05-07 09:20 ---
(In reply to comment #10)
Created an attachment (id=20592)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20592action=view) [edit]
Third draft patch
To continue the tradition: There is again something wrong
--- Comment #3 from gcc at cohi dot at 2010-05-07 09:33 ---
(In reply to comment #1)
Most likely related to PR 43277. I want to say Darwin10's unwinder is broken
...
Update: The general problem of some exceptions not being caught in
catch-clauses occurs less frequently (i.e. in less
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-07 09:40 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-07 09:46
---
There may be a dup of this bug (can't find it right now).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-07 09:53 ---
Not enough space is an error from the OS.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-07 10:11 ---
Well, it probably failed before with -funroll-loops. Why's the cpuid functions
not marked with noinline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44018
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-05-07 10:26
---
Subject: Bug 40989
Author: ebotcazou
Date: Fri May 7 10:25:54 2010
New Revision: 159149
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159149
Log:
PR 40989
* gcc-interface/misc.c
gfortran --version
GNU Fortran (GCC) 4.5.0 20100128 (experimental)
uname -a
Linux loanamd25 2.6.16.46-0.10-smp #1 SMP Mon May 7 13:37:05 UTC 2007 x86_64
x86_64 x86_64 GNU/Linux
cat used_dummy.f90
FUNCTION DGEES_SELECTH(SELECT)
LOGICAL :: DGEES_SELECTH
--- Comment #2 from crossroads at googlemail dot com 2010-05-07 11:22
---
Having to specialize for every unsigned or signed integer types makes no sense,
depends on the standard being used (e.g. if there is a long long type or not),
and whether or not the given implementation has
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-07 11:55 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-07 11:55 ---
Subject: Bug 44020
Author: rguenth
Date: Fri May 7 11:55:21 2010
New Revision: 159150
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159150
Log:
2010-05-07 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from redi at gcc dot gnu dot org 2010-05-07 12:09 ---
I didn't suggest specialising on every type, you could specialise on
numeric_limitsinteger::is_signed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
--- Comment #4 from ubizjak at gmail dot com 2010-05-07 12:19 ---
(In reply to comment #3)
Well, it probably failed before with -funroll-loops. Why's the cpuid
functions
not marked with noinline?
Because it is only one instruction?
--
--- Comment #4 from redi at gcc dot gnu dot org 2010-05-07 12:20 ---
alternatively you could just use std::lessinteger()(x, 0) which avoids the
warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44021
Recent changes broke bootstrap on alphaev68-pc-linux-gnu, due to stage2/3
compare failure in libiberty/sha1.o.
Soon to be attached preprocessed file triggers -fcompare-debug failure (also on
a crosscompiler from x86_64-pc-linux-gnu):
~/gcc-build-alpha/gcc/xgcc -B ~/gcc-build-alpha/gcc -mcpu=ev67
--- Comment #1 from ubizjak at gmail dot com 2010-05-07 12:39 ---
Created an attachment (id=20595)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20595action=view)
preprocessed source
Preprocessed source (can be compiled on a crosscompiler), triggers stage2/3
bootstrap compare
--- Comment #5 from hjl dot tools at gmail dot com 2010-05-07 13:08 ---
For some reason, when I change it to C, it compiles.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-07 13:08 ---
Manuel: As this is a middle-end warning, do you have an idea?
dgees_selecth (logical(kind=4) (*T410) (void) select)
{
logical(kind=4) __result_dgees_selecth.0;
logical(kind=4) D.1538;
logical(kind=4)
The commit
http://gcc.gnu.org/viewcvs?view=revisionrevision=122551
changed gcc's behaviour in
-
int bar();
int a = ((void *) bar) != 0;
We used to accept it, but now we produce
test.c:2: error: initializer element is not constant
--- Comment #5 from bangerth at gmail dot com 2010-05-07 13:15 ---
*** This bug has been marked as a duplicate of 11856 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #28 from bangerth at gmail dot com 2010-05-07 13:15 ---
*** Bug 44021 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
Compile the attached source code with options -Os -march=armv7-a -mthumb, gcc
generates:
bar4:
push{r3, r4, r5, lr}
ldr r2, [r0, #520]
mov r4, r0
mov r3, r0
mov r1, r0
movsr0, #0// A
b .L2
.L4:
--- Comment #1 from carrot at google dot com 2010-05-07 13:19 ---
Created an attachment (id=20596)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20596action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-05-07
13:29 ---
Subject: Re: xgcc: error trying to exec
'/test/gnu/gcc/objdir/./prev-gcc/gnat1': execv: Not e
Not enough space is an error from the OS.
Yes, but I saw this on two separate machines, one with 8 GB of
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenther at suse dot de|rguenth at gcc dot gnu dot
|
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-07 13:57 ---
*** Bug 41825 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-07 13:57 ---
*** This bug has been marked as a duplicate of 30566 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Results and status of internal read are wrong if -malign-double
option is specified. Seen on (32 bit)
SLC4 gfortran 4.3.3 (i686-pc-linux-gnu),
Ubuntu9 gfortran 4.4.1 (Ubuntu 4.4.1-4ubuntu9),
rhel6 beta (4.4.3-1.el6.i386).
No problem on g77 and gfortran (4.1.2-44.EL4_8.1.i386) on SLC4,
gfortran
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-07 14:35 ---
DO NOT USE -malign-double.
You need to recompile gfortran's runtime library if this
option is to be used.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Results and status of internal read are wrong if -malign-double
option is specified. Seen on (32 bit)
SLC4 gfortran 4.3.3 (i686-pc-linux-gnu),
Ubuntu9 gfortran 4.4.1 (Ubuntu 4.4.1-4ubuntu9),
rhel6 beta (4.4.3-1.el6.i386).
No problem on g77 and gfortran (4.1.2-44.EL4_8.1.i386) on SLC4,
gfortran
--- Comment #2 from Igor dot Katchaev at cern dot ch 2010-05-07 14:47
---
Subject: Re: Segfault on internal read with -malign-double
Ok, thanks.
Please remove duplicate #44027, sorry.
Igor
On Fri, 7 May 2010, kargl at gcc dot gnu dot org wrote:
--- Comment #1 from kargl at
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-07 15:37 ---
Subject: Bug 40728
Author: dfranke
Date: Fri May 7 15:36:45 2010
New Revision: 159155
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159155
Log:
gcc/fortran/:
2010-05-07 Daniel Franke
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-07 15:40 ---
From quick skim the first difference is on a sha1.c:350 insn in *.ira dump.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44023
--- Comment #3 from burnus at gcc dot gnu dot org 2010-05-07 15:42 ---
*** Bug 44027 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44026
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-07 15:42 ---
As requested in PR 44026: Mark this report as duplicate.
Regarding the error message itself: As the manual state (man gcc or
--- Comment #3 from ubizjak at gmail dot com 2010-05-07 15:46 ---
Jakub, reverting your r159063 fixes the failure:
PR debug/43478
* df-problems.c (struct dead_debug_use, struct dead_debug): New.
(dead_debug_init, dead_debug_finish): New functions.
Command line:
$ gcc -O1 -fregmove -fsched-pressure -ftree-vectorize -funroll-loops
-fschedule-insns -fcompare-debug testcase.c
or
$ gcc -O3 -fsched-pressure -fschedule-insns -fcompare-debug testcase.c
Tested revisions:
r159062 - fail
r159045 - fail
r158683 - fail
r153685 - fail
--
--- Comment #13 from jason at gcc dot gnu dot org 2010-05-07 15:52 ---
Subject: Bug 43951
Author: jason
Date: Fri May 7 15:52:06 2010
New Revision: 159158
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159158
Log:
PR c++/43951
* init.c
--- Comment #1 from zsojka at seznam dot cz 2010-05-07 15:53 ---
Created an attachment (id=20597)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20597action=view)
reduced testcase (from gcc.c-torture/execute/20030914-1.c)
Different code is generated with x86_64-linux as target
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
Subject: Bug 43371
Author: rguenth
Date: Fri May 7 15:53:40 2010
New Revision: 159159
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159159
Log:
2010-05-07 Richard Guenther rguent...@suse.de
*
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
Subject: Bug 43857
Author: rguenth
Date: Fri May 7 15:53:40 2010
New Revision: 159159
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159159
Log:
2010-05-07 Richard Guenther rguent...@suse.de
*
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-07 15:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from dfranke at gcc dot gnu dot org 2010-05-07 16:00
---
My build log seems to be clean (i686-pc-linux-gnu).
Is this PR still needed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2010-05-07 16:32 ---
Created an attachment (id=20598)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20598action=view)
reduced testcase
Reduced testcase, 45 lines. Beware, crypto code ahead...
--
--- Comment #12 from burnus at gcc dot gnu dot org 2010-05-07 16:37 ---
Created an attachment (id=20599)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20599action=view)
Fourth version of the draft patch
And fourth version. I have just realized that the patch is too simplistic and
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-05-07 16:41
---
Any news here? Can this one be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41977
--- Comment #5 from ubizjak at gmail dot com 2010-05-07 17:04 ---
For some reason, IRA chooses different reload registers.
--- t1.c.190r.ira 2010-05-07 18:57:36.0 +0200
+++ t1.c.gk.190r.ira2010-05-07 18:57:36.0 +0200
These are differences in chosen reload
--- Comment #6 from ubizjak at gmail dot com 2010-05-07 17:12 ---
The differences in IRA insn stream dumps are then:
[...]
-$28:DI=[$30:DI+0x78]
-$28:DI=leu($28:DI,$16:DI)
-[$30:DI+0x70]=$28:DI
+$0:DI=[$30:DI+0x78]
+$0:DI=leu($0:DI,$16:DI)
+[$30:DI+0x70]=$0:DI
[...]
--- Comment #24 from nightstrike at gmail dot com 2010-05-07 17:18 ---
This is for mingw, not linux.
I can test again when our buildbot farm is back up. Should be in the next few
days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-07 17:23 ---
In openmp.c (gfc_match_omp_end_nowait), we match nowait and end-of-string. If
there's anything but whitespace after the nowait, the match is rejected.
With nowait being rejected, parse.c (match_word) rejects the
--- Comment #5 from mrs at gcc dot gnu dot org 2010-05-07 17:34 ---
Subject: Bug 43708
Author: mrs
Date: Fri May 7 17:34:31 2010
New Revision: 159164
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159164
Log:
PR target/43708
* config/darwin-c.c
--- Comment #6 from mrs at gcc dot gnu dot org 2010-05-07 17:35 ---
Thanks.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-07 17:41 ---
(In reply to comment #1)
I believe, this is eventually the same as PR32365.
Stupid me. There's actually an easy fix for this one:
Index: openmp.c
--- Comment #25 from sezeroz at gmail dot com 2010-05-07 17:44 ---
(In reply to comment #23)
My build log seems to be clean (i686-pc-linux-gnu).
Is this PR still needed?
The commit from comment #14 (as inlined in comment #9) introduces a new warning
of passing argument 2 of
--- Comment #2 from ubizjak at gmail dot com 2010-05-07 17:46 ---
The difference starts in sched1 dumps:
[...]
+{r127:XF=float(r150:SI);clobber [frame:DI-0x44];}
+REG_DEAD: r150:SI
{r160:HI=r160:HI|0xc00;clobber flags:CC;}
REG_UNUSED: flags:CC
r106:XF=r106:XF+r120:XF
REG_DEAD:
--- Comment #12 from vmakarov at redhat dot com 2010-05-07 17:49 ---
When allocno is finished, its some info is propagated into upper allocno.
When several allocnos with same regno are finished, info can be propagated
directly to survived upper allocno or through one allocno will be
--- Comment #23 from rus at google dot com 2010-05-07 17:49 ---
Subject: Re: ext/profile/all.cc fails on Solaris
On Thu, May 6, 2010 at 11:53 PM, kgardas at objectsecurity dot com
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #22 from kgardas at objectsecurity dot com 2010-05-07
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-07 18:06 ---
*** Bug 39289 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43289
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-07 18:06 ---
*** This bug has been marked as a duplicate of 43289 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-07 18:12 ---
$ gfortran-svn -v
gcc version 4.6.0 20100506 (experimental) (GCC)
$ gfortran-svn -std=f2003 pr43539.f90
pr43539.f90:9.32:
write(*,'(a,i0)') 'In f08: ', C_SIZEOF(sp)
1
Error:
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-07 18:12 ---
*** Bug 43539 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
The GNAT User Guide (source gnat_ugn.texi) is referenced in several places from
gnat_rm.texi. However, when the User Guide is built, gnat_ugn.texi is
preprocessed into gnat_ugn_unw.texi (Unix, Windows) or gnat_ugn_vms.texi (VMS),
so that the links from the Reference Manual don't work.
Go to
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-07 19:46 ---
(In reply to comment #5)
* shared DO termination
Ahh, I'd like to see that one!
(In reply to comment #6)
That's your PR40165 ;)
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-07 19:50 ---
(In reply to comment #5)
I tried 4.4.2 and do not any longer see the segfault on the Cray XT system.
This PR can thus be closed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r159144-install
--program-prefix=r159144- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100507 (experimental) (GCC)
[reg...@bethe tmp601]$ current-gcc -O2 -c small.c
small.c: In function 'func
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-07 19:53 ---
Paul, this PR seems to be fixed. Can it be closed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-07 19:56 ---
Paul, any reason not to commit the patch in comment #1?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rwild at gcc dot gnu dot org 2010-05-07 20:10 ---
Subject: Bug 44016
Author: rwild
Date: Fri May 7 20:10:09 2010
New Revision: 159168
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159168
Log:
Fix link to outdated cxx0x status page.
gcc/:
PR
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-07 20:10 ---
(In reply to comment #2)
Therefore, I vote for a confirm.
Paul, did you mean to assign this PR to you as well? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36497
--- Comment #2 from rwild at gcc dot gnu dot org 2010-05-07 20:11 ---
Subject: Bug 44016
Author: rwild
Date: Fri May 7 20:10:32 2010
New Revision: 159169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159169
Log:
Fix link to outdated cxx0x status page.
gcc/:
PR
--- Comment #3 from rwild at gcc dot gnu dot org 2010-05-07 20:11 ---
Subject: Bug 44016
Author: rwild
Date: Fri May 7 20:11:01 2010
New Revision: 159170
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159170
Log:
Fix link to outdated cxx0x status page.
gcc/:
PR
--- Comment #4 from rwild at gcc dot gnu dot org 2010-05-07 20:11 ---
Fixed.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from scovich at gmail dot com 2010-05-07 20:12 ---
Belated follow-up: I just tried to use sparc-sun-solaris2.10-gcc-4.4.0 (built
from sources) and it does not emit the DW_AT_call_* debug attributes which gdb
expects in order to unwind inlined functions.
I have searched
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-07 20:13 ---
Slightly more reduced testcase:
void
foo (unsigned f, long v, unsigned *w, unsigned a, unsigned b, unsigned e,
unsigned c, unsigned d)
{
unsigned h = v / 4, x[16];
while (f h)
{
unsigned i;
f++;
--- Comment #4 from hjl dot tools at gmail dot com 2010-05-07 20:14 ---
It is caused by revision 152927:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00580.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44028
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-07 20:15 ---
This PR seems to be fixed. The dump does not contain any reference to
builtin_pack/builtin_unpack any more and I can't identify anything that looks
like a call to transfer.
Can it thus be closed?
--
dfranke at
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-07 20:24 ---
#c3 testcase is actually from PR44023. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44028
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-07 20:25 ---
Slightly more reduced testcase:
void
foo (unsigned f, long v, unsigned *w, unsigned a, unsigned b, unsigned e,
unsigned c, unsigned d)
{
unsigned h = v / 4, x[16];
while (f h)
{
unsigned i;
f++;
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-07 20:30 ---
(In reply to comment #8)
I guess everything is fixed now. Can we close this PR?
Ping?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-07 20:52 ---
It is caused by revision 159106:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00156.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
1 - 100 of 129 matches
Mail list logo
