--- Comment #104 from bonzini at gnu dot org 2009-06-16 06:47 ---
I understood that with -frename-registers the regression is fixed. As I said,
without a pre-regalloc scheduling pass and without register renaming, the
scheduling quality you get is more or less random.
--
--- Comment #6 from burnus at gcc dot gnu dot org 2009-06-16 06:57 ---
Subject: Bug 40383
Author: burnus
Date: Tue Jun 16 06:57:09 2009
New Revision: 148517
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148517
Log:
2009-06-16 Tobias Burnus bur...@net-b.de
PR
--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-16 06:57 ---
FIXED on the trunk (4.5).
Patch was: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01147.html
See also follow-up PR 40452.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #105 from bonzini at gnu dot org 2009-06-16 07:01 ---
Marking PR39157 as a duplicate of PR26854 is not exact (only the fwprop part is
a duplicate, because we were getting large compile times because of building
large data structures; the CFG Cleanup part is not exactly a
--- Comment #106 from lucier at math dot purdue dot edu 2009-06-16 07:24
---
This machine has 4ms ticks, so we're getting down to a few ticks difference
with a benchmark of this size. It's 156ms with 4.2.4, 168ms with 4.5.0, and
164 ms when -frename-registers is added to the command
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot
|dot org
--- Comment #17 from irar at il dot ibm dot com 2009-06-16 07:36 ---
Dominique,
Could you please try this patch (I changed (!a !b) to !(a || b)).
Thanks,
Ira
Index: vect-42.c
===
--- vect-42.c (revision 148487)
+++
--- Comment #2 from andreast at gcc dot gnu dot org 2009-06-16 07:38
---
Index: testsuite/lib/libffi-dg.exp
===
--- testsuite/lib/libffi-dg.exp (revision 148518)
+++ testsuite/lib/libffi-dg.exp (working copy)
@@ -187,6
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-16 08:19 ---
(In reply to comment #0)
The challenge is diagnose this properly. The problem is that the array size is
_not_ passed. One solution would be to enable the check only with -std=f95.
And for scalar dummy arguments:
On cywgin, configuring gcc trunk like this:
../gcc/configure --enable-threads=posix --enable-libgcj
--disable-sjlj-exceptions --with-system-zlib --enable-nls --enable-static
--enable-shared --enable-shared-libgcc --enable-__cxa_atexit
--disable-libmudflap --enable-version-specific-runtime-libs
--- Comment #6 from janus at gcc dot gnu dot org 2009-06-16 09:06 ---
Subject: Bug 40039
Author: janus
Date: Tue Jun 16 09:06:13 2009
New Revision: 148519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148519
Log:
2009-06-16 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #9 from janus at gcc dot gnu dot org 2009-06-16 09:06 ---
Subject: Bug 36947
Author: janus
Date: Tue Jun 16 09:06:13 2009
New Revision: 148519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148519
Log:
2009-06-16 Janus Weil ja...@gcc.gnu.org
PR
Current gcc can't make use of stm and ldm to reduce code size.
--
Summary: use stm and ldm to access consecutive memory words
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-16 09:07 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from carrot at google dot com 2009-06-16 09:11 ---
Created an attachment (id=18005)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18005action=view)
test case
For this function
void foo(int* p)
{
p[0] = 1;
p[1] = 2;
}
gcc generates:
mov r1, #1
mov r3,
--- Comment #10 from janus at gcc dot gnu dot org 2009-06-16 09:14 ---
From the ToDo items in comment #7, r148519 fixes the first two (check for
optional and better error messages). The remaining item (recursive check) is
tracked by PR 40453, so I think this PR can be closed.
--
--- Comment #7 from janus at gcc dot gnu dot org 2009-06-16 09:17 ---
r148519 improves the error messages (besides adding a check for optional), so
the remaining ToDo item for this PR is: Fixing the intents of non-std
intrinsics (which are currently all intent(in)).
--
--
christian dot joensson at gmail dot com changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40456
--- Comment #3 from dominiq at lps dot ens dot fr 2009-06-16 09:46 ---
With the patch in comment #2 I get:
=== libffi tests ===
Schedule of variations:
unix
unix/-m64
Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
--- Comment #4 from dominiq at lps dot ens dot fr 2009-06-16 09:50 ---
libffi/testsuite/libffi.call/cls_dbls_struct.c is XFAILed for
x86_64-*-linux-*. It should probably xfailed also for x86_64*darwin* and
i686-apple-darwin* with -m64.
--
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-06-16 09:54
---
Bootstrap and testing passed, submitted in
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01179.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40413
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-16 09:57 ---
Bootstrapped, tested, submitted in
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01182.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40432
--- Comment #7 from ramana at gcc dot gnu dot org 2009-06-16 10:01 ---
(In reply to comment #5)
See the attached pqp.c file.
With gcc 4.3.3, on such simplistic examples, peephole ldm and stm works:
sum:
ldr r2, .L3
ldmia r2, {r1, r3}@ phole ldm
--- Comment #2 from ramana at gcc dot gnu dot org 2009-06-16 10:03 ---
Could you check to see why store_multiple_sequence doesn't find this in the
peephole in the ARM backend ?
GCC does generate stm and ldm's in a number of other places using the old
peephole and
--- Comment #24 from paolo dot carlini at oracle dot com 2009-06-16 10:07
---
Interesting... Seems a bit too clever to me, but we'll see. I understand this
kind of patch would fix uses of std::message as installed in a locale, not, so
to speak, stand-alone uses, right? Anyway, could
--- Comment #18 from dominiq at lps dot ens dot fr 2009-06-16 10:10 ---
Could you please try this patch (I changed (!a !b) to !(a || b)).
I am currently regtesting on my ppc and it takes a long time. Meanwhile I am
not sure to understand what you expect with this change: if I am not
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-06-16 10:12
---
Subject: Bug 40413
Author: jamborm
Date: Tue Jun 16 10:11:55 2009
New Revision: 148520
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148520
Log:
2009-06-16 Martin Jambor mjam...@suse.cz
PR
--- Comment #5 from aph at gcc dot gnu dot org 2009-06-16 10:12 ---
Thanks for the patch, Andreas. Please push upstream(s).
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-16 10:16 ---
Subject: Bug 40432
Author: jamborm
Date: Tue Jun 16 10:16:40 2009
New Revision: 148522
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148522
Log:
2009-06-16 Martin Jambor mjam...@suse.cz
PR
--- Comment #19 from irar at il dot ibm dot com 2009-06-16 10:18 ---
(In reply to comment #18)
Could you please try this patch (I changed (!a !b) to !(a || b)).
I am currently regtesting on my ppc and it takes a long time. Meanwhile I am
not sure to understand what you expect with
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-16 10:24 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-06-16 10:24
---
Fixed
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from dominiq at lps dot ens dot fr 2009-06-16 10:26 ---
Yes, the problem is that we think that the test is correct and it doesn't work
because of some syntax/brackets/space problems.
I certainly don't understand the space mess. Before reaching the patch in
comment #14
--- Comment #4 from nospamname at web dot de 2009-06-16 11:06 ---
i get report of more info about -funswitch-loops
The -funswitch-loops Option seem work on gcc 4.3.0 and above not good for
speed.It generate much larger code(wma123) and code is slower in many case (try
out ffmpeg H264
--- Comment #25 from mrsam at courier-mta dot com 2009-06-16 11:07 ---
Yes, but, unfortunately, I just realized that this only partially fixes the
original issue. This would fix the use case where different parts of the
application use different locales, and different instances of
--- Comment #21 from irar at il dot ibm dot com 2009-06-16 11:08 ---
(In reply to comment #20)
What are the expected patterns for the 3 variables
with -m32 and -m64?
I am not sure, this is why I asked you if the target is
([istarget *-*-darwin*] [is-effective-target lp64]).
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16
11:26 ---
Could you re-run that with --save-temps, and attach the .i, .s, .o and .exe
files to the PR please?
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed
Combining an idee from the Linux kernel with some suggested practice building
gcc, I'm suggesting adding a --flavour= option to configure.
The point is to have several gcc versions, otherwise configured identically but
presumably different versions, installed side-by-side on the same system.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16
11:40 ---
Already fixed at r.148523, according to:
http://gcc.gnu.org/ml/gcc/2009-06/msg00339.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40456
Armwrestler Sedns Lookalike to Weigh-eInattachment: incondite.jpg
--- Comment #2 from christian dot joensson at gmail dot com 2009-06-16
12:20 ---
Created an attachment (id=18006)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18006action=view)
a.c: from conftest in intl
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
--- Comment #3 from christian dot joensson at gmail dot com 2009-06-16
12:21 ---
Created an attachment (id=18007)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18007action=view)
a.exe generated
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
--- Comment #4 from christian dot joensson at gmail dot com 2009-06-16
12:22 ---
Created an attachment (id=18008)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18008action=view)
a.i: generated with --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
--- Comment #5 from christian dot joensson at gmail dot com 2009-06-16
12:22 ---
Created an attachment (id=18009)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18009action=view)
a.s: generated with --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
--- Comment #6 from christian dot joensson at gmail dot com 2009-06-16
12:23 ---
Created an attachment (id=18010)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18010action=view)
a.o: generated with --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-16 12:35
---
I think all the assertions are simply backwards, the load() operation requires:
The order argument shall not be memory_order_release nor
memory_order_acq_rel.
so the assertions should be
--- Comment #2 from christian dot joensson at gmail dot com 2009-06-16
12:35 ---
Fixed, as far as I understand, with commit r148523,
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00503.html.
--
christian dot joensson at gmail dot com changed:
What|Removed
--- Comment #7 from nickc at gcc dot gnu dot org 2009-06-16 12:44 ---
Subject: Bug 10197
Author: nickc
Date: Tue Jun 16 12:43:58 2009
New Revision: 148526
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148526
Log:
PR 10197
* testsuite/test-demangle.c: Rename
g++.dg/abi/mangle*.C fail on darwin:
FAIL: g++.dg/abi/mangle11.C (test for warnings, line 10)
FAIL: g++.dg/abi/mangle11.C (test for excess errors)
FAIL: g++.dg/abi/mangle12.C (test for warnings, line 11)
FAIL: g++.dg/abi/mangle12.C (test for excess errors)
FAIL: g++.dg/abi/mangle17.C (test for
The following code leads to enormous memory usage (4GB) during compilation
with -O2 or -O3 optimization. The same problem occurs also in previous g++
versions (e.g. 4.3.3, 4.2.4, 4.1.3).
#include iostream
int main() {
for (int i=0;i1;++i) {
std::cout
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-16 13:01 ---
Use --program-transform-name / --program-suffix. Directory names already
contain the gcc version.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-16 13:09 ---
Confirmed. Exponential memory use at -O2:
26 factors: 650MB
27 factors:1255MB
28 factors:2459MB
oops... ;)
26 factor testcase:
#include iostream
int main()
{
for (int i=0;i1;++i)
std::cout
--- Comment #22 from dominiq at lps dot ens dot fr 2009-06-16 13:13 ---
On the other hand, I don't understand the difference with -m32 and -m64. It
seems to me, that ([istarget *-*-darwin*] [is-effective-target lp64]) is
false for -m32 and, possibly, true for -m64. But that
--- Comment #2 from kai dot extern at googlemail dot com 2009-06-16 13:18
---
Subject: Re: gcc flavours
rguenth at gcc dot gnu dot org schrieb:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-16 13:01
---
Use --program-transform-name / --program-suffix.
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-16 13:20 ---
Oh, this is yet another case of SCEV going crazy..., called from complete
unrolling in this case.
0x0118bcc5 in chrec_fold_multiply (type=0x77ee8540,
op0=0x7273a500, op1=0x77f14b40)
at
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-16 13:23
---
for the record: http://gcc.gnu.org/ml/gcc/2009-06/msg00173.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-16 13:42 ---
chrec_fold_multiply_poly_poly is exponential...
Why does {0, +, 1}_1 * {0, +, 1}_1 yield {0, +, {1, +, 2}_1}_1? Shouldn't
we just punt if we generate exponential chrecs? Will we ever be able to
do something
--- Comment #4 from jakub at gcc dot gnu dot org 2009-06-16 13:48 ---
Subject: Bug 40446
Author: jakub
Date: Tue Jun 16 13:48:07 2009
New Revision: 148533
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148533
Log:
PR middle-end/40446
* expr.c (expand_expr_real_1)
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-16 14:01 ---
It looks like the fix is
Index: gcc/tree-chrec.h
===
--- gcc/tree-chrec.h(revision 148523)
+++ gcc/tree-chrec.h(working copy)
@@ -132,7 +132,8
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-16 14:22 ---
Add c.l.f link, mentioned in comment 9
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7bbe1ee44c505be8/
Regarding TARGET_MANGLE_DECL_ASSEMBLER_NAME (comment 2):
Currently, the decorating
--- Comment #5 from jakub at gcc dot gnu dot org 2009-06-16 14:29 ---
Subject: Bug 40446
Author: jakub
Date: Tue Jun 16 14:28:47 2009
New Revision: 148536
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148536
Log:
PR middle-end/40446
* expr.c (expand_expr_real_1)
--- Comment #6 from jakub at gcc dot gnu dot org 2009-06-16 14:30 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-16 14:36 ---
Obviously a regression against pre-tree-ssa.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-16 15:14 ---
Or use --enable-version-specific-runtime-libs .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
--- Comment #2 from mikpe at it dot uu dot se 2009-06-16 15:17 ---
(In reply to comment #0)
gcc-m68k-ice.c:28: internal compiler error: in reload_cse_simplify_operands,
at
postreload.c:393
If any of the options -m5307, -msep-data, or -O1 is removed, the problem goes
away.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-16 15:19 ---
I think these peepholes should moved over to peephole2 also if that area is
being touched.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I downloaded
http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/gcc-trunk-x86_64.tar.gz and
attempted to compile the following module:
MODULE Nonlin_Conf_Regions
CONTAINS
SUBROUTINE halprn(deriv)
INTERFACE
SUBROUTINE deriv(wt)
REAL, INTENT(IN) :: wt
END SUBROUTINE deriv
END INTERFACE
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-16 15:40
---
(In reply to comment #4)
Or use --enable-version-specific-runtime-libs .
That's been broken for some time on x86_64, see bug 32415
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-06-16 15:50
---
You haven't specified what compilation options you were using.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
While bootstrapping mainline as of 2009012 (rev 148427) on IRIX 6.5 (with the
O32 multilib excluded to work around PR libfortran/40344), compilation of
mlib-tgt.adb fails:
r...@columba 211 pwd
/vol/gcc/obj/gcc-4.5.0-20090612/6.5-gcc-no-o32/gcc/ada/tools
r...@columba 212 ../../xgcc -B../../ -c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from mcvick_e at iname dot com 2009-06-16 16:24 ---
Similar behavior has been seen against version 4.3.2.
Using the __attribute__ mechanism in the past has forced the hand of the
alignment issue most all of the time. I say most all of the time because we
have uncovered
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-16 16:27 ---
Does the http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01125.html
patch help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40462
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
--- Comment #5 from mikpe at it dot uu dot se 2009-06-16 16:29 ---
(In reply to comment #4)
Works with 4.3.1. Should this be closed if someone can confirm it is fixed on
the trunk?
This is a generic m68k issue as I can easily reproduce the ICE using a
gcc-4.2.4 based cross-compiler
--- Comment #10 from mcvick_e at iname dot com 2009-06-16 16:30 ---
The __attribute__ mechanism works in 4.0.1, but was broken in the 4.3 series.
I wanted to clarify this as I think it's an important hint as to the root cause
of the problem. In 4.0.1, packing and aligning worked via
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-06-16 16:31
---
The alignment of the variable is different from the alignment of the type ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-16 16:35 ---
Note information I got from Kai. (He was not 100% sure for some of the items
and I probably misunderstood also parts thus take with a grain of salt.)
With the stdcall attribute on Win32 the @n suffix is
--- Comment #12 from mcvick_e at iname dot com 2009-06-16 16:55 ---
Can you be a bit more succinct here? Because the comment just made sounds like
a bunch of foo foo stuff made up to ignore a genuine bug in the compiler.
Type byte has a byte alignment.
Type short has a 16-bit
--- Comment #13 from joseph at codesourcery dot com 2009-06-16 17:26
---
Subject: Re: wrong size of struct with some bit-fields on
ppc-eabi
On Tue, 16 Jun 2009, mcvick_e at iname dot com wrote:
Furthermore, as stated numerous comments back with a link to the actual PPC
ABI,
/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/armv5tejl-unknown-linux-gnueabi/bin/
-B/hom
e/dave/opt/gnu/gcc/gcc-4.5.0/armv5tejl-unknown-linux-gnueabi/bin/
-B/home/dave/o
--- Comment #6 from andreast at gcc dot gnu dot org 2009-06-16 17:28
---
Subject: Bug 40444
Author: andreast
Date: Tue Jun 16 17:28:29 2009
New Revision: 148542
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148542
Log:
2009-06-16 Andreas Tobler a.tob...@schweiz.org
--- Comment #7 from andreast at gcc dot gnu dot org 2009-06-16 17:30
---
Fixed.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-16 17:36 ---
I think the error is a valid error. For comparison, NAG f95 5.1 shows the
following error message:
Error: line 19: Dummy proc DERIV arg 1 has different INTENT from actual proc
LOGISTIC4 arg
Error: line 19:
--- Comment #26 from peturrun at gmail dot com 2009-06-16 19:51 ---
Wouldn't it be easy to implement catalogs using a vector? If do_open adds the
catalog name to the vector and returns the index, do_get can get the name back
by using the catalog as the index into the vector.
--
--- Comment #15 from joseph at codesourcery dot com 2009-06-16 20:03
---
Subject: Re: sizeof() and __attribute__ broken with
bit-fields on ppc-eabi
On Tue, 16 Jun 2009, mcvick_e at iname dot com wrote:
Thanks for the update. I finally feel as though this is getting some teeth.
Japan flaming toilet troubles heat up frutheerattachment: defat.jpg
I need to walk the stack from within an asynchronous signal handler, and every
once in a while, the program crashes in uw_frame_state_for. I know that
unwinding through a signal handler is 'discouraged', and that proper unwinding
information may not always be there, but the unwinder should fail
--- Comment #5 from dominiq at lps dot ens dot fr 2009-06-16 20:30 ---
I have forgotten this one!
This is not darwin-specific, I also see it happening on x86_64-linux.
And what's more, the output changes between -m32 and -m64.
This is probably related to the extra precision for
--- Comment #6 from kargl at gcc dot gnu dot org 2009-06-16 21:02 ---
(In reply to comment #5)
The code is invalid Fortran, so gfortran is not required to give
any sensible output.
You know that it is not relevant for this pr!-( would the following make you
happier?)
It most
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-16 21:32 ---
Wrong quote - and wrong statement. It is not a F2003 change, but already in
F95.
Fortran 95 has (12.4.1.4 Sequence association)
If the actual argument is of type default character and is an array
expression, array
--- Comment #27 from mrsam at courier-mta dot com 2009-06-16 21:54 ---
I thought of that, but using a vector will not be thread safe. Although I
don't believe that the C++ standard requires thread safety for std::messages,
applications will definitely expect thread safety here. The
--- Comment #28 from paolo dot carlini at oracle dot com 2009-06-16 22:03
---
mutexes in general can be used and are used in various places in the library
(but, for the record, we are currently a bit worried by performance issues
having to do with the one for the global locale, we have
Executing on host: /home/dave/gnu/gcc-4.5/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4
.5/objdir/gcc/
/home/dave/gnu/gcc-4.5/gcc/libffi/testsuite/libffi.call/cls_multi
_schar.c -O2 -I/home/dave/gnu/gcc-4.5/objdir/hppa-linux/./libffi/include
-I/ho
me/dave/gnu/gcc-4.5/gcc/libffi/testsuite/../include
-languages=c,c++,objc,fortran,obj-c++,java,ada
Thread model: posix
gcc version 4.5.0 20090616 (experimental) [trunk revision 148510] (GCC)
The problem is the following assembly code:
0x000104e4 f+56: cmpb,,n ret0,r19,0x104e8 f+60
0x000104e8 f+60: b,l 0x104a8 ff,rp
0x000104ec f+64: ldi 1
Compiling the following code with -O2 -W -Wall, gcc-3.2 gives a warning:
p.c: In function `bar':
p.c:4: warning: `res' might be used uninitialized in this function
No open branch does, anymore.
p.c:
int
bar(int foo)
{
int res;
if (foo) {
} else {
res = 0;
}
return res;
}
int
--- Comment #3 from daney at gcc dot gnu dot org 2009-06-17 00:23 ---
At r 148555 on x86_64-pc-linux-gnu I can confirm:
[da...@dd_xps junk]$ /home/daney/gccsvn/native-clean/gcc/g++
-B/home/daney/gccsvn/native-clean/gcc/ -fomit-frame-pointer -m32 -S dd1.cc
dd1.cc: In function void
--- Comment #1 from danglin at gcc dot gnu dot org 2009-06-17 01:15 ---
The rtl looks like this:
(gdb) p debug_rtx_list (insn, 10)
(jump_insn:TI 18 16 19
/home/dave/gnu/gcc-4.5/gcc/gcc/testsuite/gcc.c-torture/execute/20061031-1.c:19
(set (pc)
(if_then_else (ne (reg:SI 19 %r19
--- Comment #15 from amylaar at gcc dot gnu dot org 2009-06-17 04:20
---
The problem was due to USEs of SYMBOL_REFs that were emitted by the target
code.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from amylaar at gcc dot gnu dot org 2009-06-17 04:27
---
Subject: Bug 39254
Author: amylaar
Date: Wed Jun 17 04:27:29 2009
New Revision: 148568
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148568
Log:
PR target/39254
* config/rs6000/rs6000.c
1 - 100 of 103 matches
Mail list logo
