--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-06-17 06:58
---
Still missing are:
DREAL (GNU extension)
LSHIFT (GNU extension)
RSHIFT (GNU extension)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-17 04:49 ---
On trunk, this bug was fixed by revision 146817.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40470
On x86, I got
[...@gnu-6 strcasestr]$ cat /tmp/foo.c
#include
__m128i load (char *);
char *
foo (const unsigned char *s1, const unsigned char *s2,
int bmsk, __m128i frag2)
{
int len = 0;
char *p1 = (char *) s1;
char *p2 = (char *) s2;
__m128i frag1, fruc, mask;
int cmp_c, cmp_s;
if(
--- Comment #17 from amylaar at gcc dot gnu dot org 2009-06-17 04:37
---
I have applied the patch to the trunk. Should I apply it to the 4.4 release
branch as well?
--
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=gcc&view=rev&rev=148568
Log:
PR target/39254
* config/rs6000/rs6000.c (r
--- 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 #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 [1
--- 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 g(in
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
main
-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 : cmpb,<>,n ret0,r19,0x104e8
0x000104e8 : b,l 0x104a8 ,rp
0x000104ec : ldi 1,r26
This
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
-I/
--- 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
--- 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 unde
--- 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 #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
--- 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
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 gra
Japan flaming toilet troubles heat up frutheer<>
--- 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.
--- 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.
--
http
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-16 19:41 ---
Putting a standard header inside a namespace is undefined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from tbm at cyrius dot com 2009-06-16 19:41 ---
Forgot to say that adding a
#include
at the beginning helps.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40465
--- Comment #2 from tbm at cyrius dot com 2009-06-16 19:40 ---
In file included from /usr/include/stdio.h:903,
from t.cc:4:
/usr/include/bits/stdio.h: In function 'int zlib_stream::vprintf(const char*,
__va_list_tag*)':
/usr/include/bits/stdio.h:39: error: cannot convert
--- Comment #1 from tbm at cyrius dot com 2009-06-16 19:39 ---
#include
namespace zlib_stream {
#include
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40465
When I compile the following code with gcc 4.4 and -O I get a lot of header
related errors. This doesn't happen without -O or with gcc 4.3.
Is this error expected, and if so, is there any way to improve the output from
gcc to make it clearer what's going on?
--
Summary: [4.4 Regress
--- Comment #5 from ubizjak at gmail dot com 2009-06-16 18:16 ---
(In reply to comment #2)
> Could you check to see why store_multiple_sequence doesn't find this in the
> peephole in the ARM backend ?
Registers also need to be consecutive, starting from certain register, i.e.:
str
--enable-java-awt=xlib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
Thread model: posix
gcc version 4.5.0 20090616 (experimental) [trunk revision 148510] (GCC)
--
Summary: FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler
error) at -O
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2009-06-16
17:51 ---
Subject: Re: [4.5 Regression] ICE in dwarf2out_begin_epilogue, at
dwarf2out.c:2773 while compiling mlib-tgt.adb
jakub at gcc dot gnu dot org writes:
> Does the http://gcc.gnu.org/ml/gcc-patches/2009-06/ms
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-16 17:50 ---
(In reply to comment #0)
> This is presumably connected with PR 36947/40039 written by Janus Weil.
Indeed.
> I don't know whether the error message is valid.
It surely is, since the interfaces of your subroutines '
--- Comment #14 from mcvick_e at iname dot com 2009-06-16 17:42 ---
Thanks for the update. I finally feel as though this is getting some teeth. I
don't know what the default behavior of the 4.3.2 compiler is, however the
command line that I used to invoke this behavior excluded any bit
--- 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: Incompatib
--- 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
Status|ASSIGN
--- 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=gcc&view=rev&rev=148542
Log:
2009-06-16 Andreas Tobler
PR libffi/40444
/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
pt/gnu/gcc/gcc-4.5.0/armv5tejl-unknown-linux-gnueabi/lib
--- 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, bitf
--- 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 alignment
--- 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 @ suffix is automatically
--- 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 #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 __a
--- 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
--
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 #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
--- 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 a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
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
--- 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
---
--- 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
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 #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
--
--- 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 #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 #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 #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 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=gcc&view=rev&rev=148536
Log:
PR middle-end/40446
* expr.c (expand_expr_real_1)
--- 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 (@) s
--- 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 #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=gcc&view=rev&rev=148533
Log:
PR middle-end/40446
* expr.c (expand_expr_real_1)
--- 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 reason
--- 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 #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 #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. Dir
--- 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 cont
--- 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
int main()
{
for (int i=0;i<1;++i)
std::cout << (i*i*i*i*i*i*i*i*i
--- 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
--
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
int main() {
for (int i=0;i<1;++i) {
std::cout <<
(i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i*i
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
--- 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=gcc&view=rev&rev=148526
Log:
PR 10197
* testsuite/test-demangle.c: Rename getl
--- 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 #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
__glibcxx_assert
--- 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=18010&action=view)
a.o: 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=18009&action=view)
a.s: generated with --save-temps
--
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=18008&action=view)
a.i: generated with --save-temps
--
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=18007&action=view)
a.exe generated
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
--- 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=18006&action=view)
a.c: from conftest in intl
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
Armwrestler Sedns Lookalike to Weigh-eIn<>
--- 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
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. T
--- 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
--- 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]).
vec
--- 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 std::m
--- 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 de
--- 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
--- 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
Status|ASSIGNED
--- 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 #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
--- 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=gcc&view=rev&rev=148522
Log:
2009-06-16 Martin Jambor
PR tree-optimization/404
--- 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 #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=gcc&view=rev&rev=148520
Log:
2009-06-16 Martin Jambor
PR tree-optimization/4
--- 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 no
--- 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 #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 store_multiple_sequenc
--- 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 #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 #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 #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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- 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
--
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 #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)).
--
http://gcc.gn
--- 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.
--
jan
--- 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=18005&action=view)
test case
For this function
void foo(int* p)
{
p[0] = 1;
p[1] = 2;
}
gcc generates:
mov r1, #1
mov r3,
1 - 100 of 111 matches
Mail list logo
