On Wed, 15 Apr 2009, DJ Delorie wrote:
yes; however, maybe it would be easier to wait till Richard finishes the
work on not representing the overflow semantics in types (assuming that's
going to happen say in a few weeks?), which should make the fix
unnecessary,
Another thought - is
Note that the issue is with our representation of POINTER_PLUS_EXPR
which insists on using sizetype for the pointer offset argument
(where I don't remember if m32c uses a bigger or smaller mode for
sizetype than for pointers). Whenever the sizes of the modes for
pointers and sizetype do not
On Wed, 15 Apr 2009, DJ Delorie wrote:
As of this fix (yes, I know it was some time ago - I've been busy),
the m32c-elf build fails building the target libiberty:
./cc1 -fpreprocessed regex.i -quiet -dumpbase regex.c -mcpu=m32cm \
-auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-strings
All the problems of PPL 0.10.1 we are aware of have been
fixed in the snapshot of PPL 0.10.2 available at
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
In particular here is what has changed:
- Correctly detect GMP 4.3.0.
- Fixed the C interface library version information.
- Test program
On Thu, Apr 16, 2009 at 2:08 PM, Roberto Bagnara bagn...@cs.unipr.it wrote:
All the problems of PPL 0.10.1 we are aware of have been
fixed in the snapshot of PPL 0.10.2 available at
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
In particular here is what has changed:
- Correctly detect GMP
I'm not sure if this is the same problem, but didn't I suggest in
the past to fix this up during expansion? That is, if we end up
with a POINTER_PLUS_EXPR with different mode size pointer and offset
promote (or demote) the offset argument to pointer size properly?
What happened to these
Suggested Messaging: Messaging seems redundant in indicating that function has
been redifined twice. One of the messages should be removed. More to the point,
I think the messaging may be erroneous - code fragment follows.
g++-4 Diagnostic Messaging
In file included from partition.cpp:66:
On Thu, Apr 16, 2009 at 12:06 PM, Arthur Schwarz
aschwarz1...@verizon.net wrote:
Suggested Messaging: Messaging seems redundant in indicating that function
has been redifined twice. One of the messages should be removed. More to the
point, I think the messaging may be erroneous - code
Can you show code that reproduces the issue? My best
guess is that a
header file is included twice, and lacks guards, hence the
message is
correct: the function is being defined twice, from the same
source
location.
-- James
Code (unadulterated and full of original
I forgot to say 'thanks James', thanks.
Well, spurred on by the whimsy that I need a solution to the problem (however
dolorous), I experimented. I've commented most everything at least once and the
net effect is that only the 'operator' gets a nasty message. I've checked the
include files
Thanks to everyone.
The rock has dropped. The answer is quoted below:
My best guess is that a header file is included twice, and lacks guards, hence
the message is correct: the function is being defined twice, from the same
source location.
I had put my friends following my 'include guard'.
Snapshot gcc-4.5-20090416 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090416/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote:
The rock has dropped. The answer is quoted below:
My best guess is that a header file is included twice, and lacks guards,
hence the message is correct: the function is being defined twice, from the
same source location.
Yes,
Hi All,
Is there any advantage of using switch-case over if-else. I mean any internal
optimizations, gcc can do on a Linux i386 machine?.
Is it saving any machine instructions for us ?.
Regards,
Shameem
_
So many new options, so
Ian Lance Taylor wrote:
My plan going forward is as follows (when we are back in stage 1):
FWIW, I think this is a great plan.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
On Thu, Apr 16, 2009 at 09:07:58PM -0700, Shameem Ahamed wrote:
Is there any advantage of using switch-case over if-else. I mean any internal
optimizations, gcc can do on a Linux i386 machine?.
The optimizations in question are architecture-independent, though there
would undoubtedly be
On Thu, Apr 16, 2009 at 10:12:10PM -0700, Joe Buck wrote:
I don't know how much of that work got into the compiler, probably
it isn't in the 4.2.x version we're using now.
I should clarify that remark. In production work right now I'm
not using the current gcc, and am not using
--- Comment #9 from sebastian dot wenzler at hp dot com 2009-04-16 06:40
---
I had the same problem with Solaris 10 on sparcv9 with gcc-4.3.3.
Environment:
1) binutils/2.15 2) bison/1.875 3) automake/1.4-p5 4) gcc/4.2.4
The following program
CHARACTER(LEN=80) DATA
DATA=
OPEN(121245,FILE=/proc/self/statm,ACTION=READ,STATUS=OLD,ACCESS=STREAM)
DO I=1,80
READ(121245,END=999) DATA(I:I)
ENDDO
999 CLOSE(121245)
DATA(I:80)=
END
under valgrind leads to :
==29139==
--- Comment #1 from jv244 at cam dot ac dot uk 2009-04-16 07:31 ---
no valgrind errors with g95 or NAG.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:33
---
Created an attachment (id=17646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17646action=view)
Reduced testcase.
To be gnatchop-ed and compiled at -O.
--
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:57
---
Richard,
the removal of
/* If the RHS of the MODIFY_EXPR may throw or make a nonlocal goto
and the LHS is a user variable, then we need to introduce a formal
temporary. This way the optimizers can
--- Comment #2 from bonzini at gnu dot org 2009-04-16 08:04 ---
Subject: Re: [cond-optab] CSE does not put subregs into
COMPAREs on many CC0 machines
Is this a cond-optab regression or just an observation?
Yes, it causes extra moves on code using unions. Where we have
--- Comment #30 from rguenther at suse dot de 2009-04-16 08:06 ---
Subject: Re: [4.5 regression] Revision 145338 breaks
ability to build Ada
On Thu, 16 Apr 2009, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:57
--- Comment #1 from ubizjak at gmail dot com 2009-04-16 08:28 ---
Confirmed also on i686-pc-linux-gnu.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2009-04-16 08:33
---
Do you happen to have a testcase?
Attached in the PR.
bb 22:
formal_24(ab) = p__proc_next (formal_6(ab));
goto bb 3;
# formal_7(ab) = PHI formal_9(ab)(2), formal_5(ab)(3), formal_5(ab)(4),
--- Comment #2 from ubizjak at gmail dot com 2009-04-16 08:35 ---
It doesn't fail for me on linux-mingw cross. Can you please provide the
backtrace?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
--- Comment #32 from rguenther at suse dot de 2009-04-16 08:45 ---
Subject: Re: [4.5 regression] Revision 145338 breaks
ability to build Ada
On Thu, 16 Apr 2009, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2009-04-16 08:33
It is not possible to use -ftls-model to set the tls-model to global-dynamic
for code compiled without -fpic. Code compiled without -fpic uses initial-exec
or local-exec.
This makes it impossible to link code that uses tls and is compiled without
-fpic in shared libraries.
--
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2009-04-16 09:13
---
Ok, so we _do_ run lower_eh_constructs, but
formal = p__proc_next (formal);
returns false for stmt_could_throw_p (stmt). Why? (Not that I can follow
the Ada testcase ... but I suppose the above
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 regression] Revision |[4.5 Regression] Revision
|145338 breaks ability
--- Comment #17 from nospamname at web dot de 2009-04-16 09:22 ---
I get same align problem on 68k amigaos Target.the rport and fix is old.
its a middle end bug and i see the fix is not in the source i download (4.3.3)
i can test this patch if you like, or have you something more new ?
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-04-16 10:45
---
Maybe fixed now (the reduced testcase is). Please re-open if not.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-04-16 08:59
---
And of course the testcase compiles fine with -fexceptions. Hmmm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-04-16 08:58
---
Ok, so we _do_ run lower_eh_constructs, but
formal = p__proc_next (formal);
returns false for stmt_could_throw_p (stmt). Why? (Not that I can follow
the Ada testcase ... but I suppose the above function call
--- Comment #36 from rguenth at gcc dot gnu dot org 2009-04-16 09:22
---
Created an attachment (id=17647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17647action=view)
patch
Ok, I think I see the issue. The attached patch should fix it (it does fix
the testcase). I am going
--- Comment #2 from irar at il dot ibm dot com 2009-04-16 10:26 ---
This patch fixes the type in pr34591.c (the vector type should be the type of
the reduction variable because we are looking for its initial value, and not
the type of the reduction statement, i.e., its RHS type):
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-16 11:29 ---
An example can be found in the following paper:
Norman S. Clerman: Note on creating an array of procedure pointers
ACM SIGPLAN Fortran Forum, Vol. 28, Issue 1 (2009)
http://doi.acm.org/10.1145/1520752.1520753
--
--- Comment #2 from ubizjak at gmail dot com 2009-04-16 11:37 ---
It looks that convert_modes has some issues. When expanding shift RTX,
convert_modes is called from
#0 convert_modes (mode=QImode, oldmode=QImode, x=0xb7d05fe8, unsignedp=0) at
../../gcc-svn/trunk/gcc/expr.c:769
#1
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-16 12:07 ---
I'm bootstrapping / testing the patch and will take care of committing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kuchen_ at gmx dot de 2009-04-16 12:00 ---
The backtrace from gcc? How do I get that? (It's not crashing, so it's hard to
find the point from which the backtrace should be generated...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
--- Comment #3 from ubizjak at gmail dot com 2009-04-16 12:26 ---
This testcase fails for all optimization levels:
--cut here--
/* { dg-do compile } */
/* { dg-options -w } */
int test (char v1)
{
v1 = 0xdebecced;
return v1;
}
--cut here--
Follwing patch fixes the failure, but
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-16 12:45 ---
Subject: Bug 39698
Author: rguenth
Date: Thu Apr 16 12:44:46 2009
New Revision: 146180
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146180
Log:
2009-04-16 Richard Guenther rguent...@suse.de
Ira
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-16 12:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jv244 at cam dot ac dot uk 2009-04-16 12:56 ---
seemingly works fine with 4.2.3
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Summary|[4.5/4.4/4.3 Regression] IO |[4.3/4.4/4.5 Regression] IO
|depends on uninitialised
--- Comment #4 from ubizjak at gmail dot com 2009-04-16 13:09 ---
(In reply to comment #3)
The backtrace from gcc? How do I get that? (It's not crashing, so it's hard to
find the point from which the backtrace should be generated...)
gdb /some/dir/cc1
(gdb) break fancy_abort
(gdb)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 13:52 ---
code in shared libraries have to be PIC code
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kuchen_ at gmx dot de 2009-04-16 14:01 ---
Thanks for help!
(gdb) run
Starting program: C:\osdev\kos/..\tools\gcc-4.3.3\i586-elf\bin\cc1.exe
-Iinclude
-Iinclude/arch/i386 -Ikernel/include -O3 -g -ffreestanding -Wall -o virt.o
ker
nel/mm/virt.c
[New thread
--- Comment #2 from tom dot aernoudt at coware dot com 2009-04-16 14:07
---
Aren't shared libraries that are compiled without -fPIC supposed to work on
x86?
On other platforms this may not work, but I thought that on x86 this is not
required.
--
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-16 14:16 ---
(In reply to comment #2)
Aren't shared libraries that are compiled without -fPIC supposed to work on
x86?
It is not supposed to work. It is happens to work. Now it happens not
to work for this combination.
--
--- Comment #5 from gcc at abeckmann dot de 2009-04-16 14:28 ---
It does compile successfully using 4.4.0 built with --enable-checking. Is there
anyting else to enable these tree checks?
$ x86_64-linux-gnu-g++-4.4.x -v -c PR39754.min.ii echo SUCCESS
Using built-in specs.
Target:
--- Comment #4 from tom dot aernoudt at coware dot com 2009-04-16 14:52
---
That may be true, but if it would be possible to tell gcc to use the
dynamic-global tls-model (or static-global) without specifying -fPIC it would
again 'happen' to work, even if tls is used.
I don't see a
--- Comment #2 from msieweke at broadcom dot com 2009-04-16 15:06 ---
As mentioned in the original report, the bug doesn't exist in GCC 4.x.x. It
has since been tested with GCC 3.4.4, where the bug is fixed.
GCC 3.2.x - broken
GCC 3.3.x - broken
GCC 3.4.x - fixed
GCC 4.x.x - fixed
For
--- Comment #2 from vmakarov at gcc dot gnu dot org 2009-04-16 15:16
---
Subject: Bug 39762
Author: vmakarov
Date: Thu Apr 16 15:15:48 2009
New Revision: 146198
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146198
Log:
2009-04-16 Vladimir Makarov vmaka...@redhat.com
--- Comment #16 from pinskia at gcc dot gnu dot org 2009-04-16 15:42
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 15:43
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-04-16 15:43 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 15:43 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-16 15:43
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-04-16 15:44
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-16 15:44
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 15:44 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 15:44
---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 15:45 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 15:48 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from sje at cup dot hp dot com 2009-04-16 15:48 ---
It looks like you already fixed it on the mainline, is there a reason the
patch can't be backported to the 4.3 branch and the defect closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-16 15:56 ---
Try bisecting the changes to cherry-pick the one fixing the bug.
Fixed in GCC 3.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 16:04 ---
Actually it is just better to check the tree code, testing the patch right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39365
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-16 16:07 ---
Fixed in 4.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-16 16:13 ---
This looks like better optimizations is causing a latent bug in the
selective-scheduling to show up.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aam at fastmail dot fm 2009-04-16 16:18 ---
export ABI=32
I used this to tell GMP and MPFR that I wanted 32-bit libraries, which GCC
4.3.3 seemed to need rather than the default of 64-bit libraries which causes
the GCC configure script to fail to detect the proper
--- Comment #36 from pinskia at gcc dot gnu dot org 2009-04-16 16:22
---
Fixed via Ira so marking as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 16:35
---
Fixed at least on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 16:50 ---
The testcase from comment #7 is correctly rejected but the testcase from
comment #0 is ICEing now which makes this a regression as 4.4.0 20090101
accepted it.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 16:53 ---
(In reply to comment #4)
But this is valid and is rejected by gcc but accpected by ICC:
This is now accepted on the trunk.
friend Sint::Sint(); is still rejected but I don't know if that is valid
or not.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-16 16:55 ---
Vlad, do you plan to commit to 4.4 branch as well?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-16 16:59 ---
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01249.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35423
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-16 17:02 ---
Fixed in at least 4.4.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from igodard at pacbell dot net 2009-04-16 17:02 ---
Wow! Six years and counting! This might be my oldest outstanding bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 17:03 ---
Mine to commit the testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-16 17:07 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 17:07 ---
Subject: Bug 28766
Author: pinskia
Date: Thu Apr 16 17:07:06 2009
New Revision: 146203
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146203
Log:
2009-04-16 Andrew Pinski pins...@gmail.com
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-16 17:08 ---
Fixed in at least 4.4.0.
Mine to commit the testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-16 17:16 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 17:16 ---
Subject: Bug 17570
Author: pinskia
Date: Thu Apr 16 17:15:59 2009
New Revision: 146206
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146206
Log:
2009-04-16 Andrew Pinski pins...@gmail.com
PR
--- Comment #6 from kargl at gcc dot gnu dot org 2009-04-16 17:31 ---
well, that was an inconvenient goose chase. (Note to self:
always check the Standard).
I'm tempted to close this with INVALID because the F95 Standard
explicitly states that SIZE() has a
Result Characteristics.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:22 ---
I think libstdc++ include pathes make the error message useless but if the
user code had the same walking back, I think the user would say this is more
useful message than what is recommended in comment #0 (at
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:24 ---
First there are a couple of issues here:
1) accepts invalid code:
using namespace std;
2)
foo.cc:3: error: ifstream does not name a type
Yes that should change if ifstream is not defined at all but we still
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-16 18:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:26 ---
foo.cc:6: error: std::ifstream was declared but not defined
This is even more confusing to me. As incomplete types are understood easier
than just being declared and not defined.
--
pinskia at gcc dot gnu
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:28 ---
The problem is that GCC does not give an error
It can't give an error for that code as it is only runtime undefined and it
does not have to be invoked at runtime (i.e. the function is not called).
-- Pinski
--
--- Comment #2 from scottwood at freescale dot com 2009-04-16 18:30 ---
(In reply to comment #1)
The problem is that GCC does not give an error
It can't give an error for that code as it is only runtime undefined and it
does not have to be invoked at runtime (i.e. the function is
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 18:33 ---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 18:33
---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-04-16 18:33
---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-16 18:34
---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 18:34 ---
Stop setting the target milestone unless it is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 18:37 ---
Confirmed:
==21080== Conditional jump or move depends on uninitialised value(s)
==21080==at 0x4BD8A78: finalize_transfer (transfer.c:3147)
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-16 18:45
---
stw %r3,RR'shrd.1301-$global$(%r1)
.CALL
bl GOMP_atomic_end,%r2
nop
.CALL
bl GOMP_barrier,%r2
nop
comib,= 4,%r3,L$0006
ldw -84(%r30),%r2
1 - 100 of 161 matches
Mail list logo
