Since Fortran 2003, the intrinsics MINLOC, MAXLOC, MINVAL, MAXVAL allow the
array argument to be of CHARACTER type (in addition to INTEGER or REAL).
Currently, only INTEGER and REAL are supported, though.
--
Summary: Support CHARACTER argument with
MINLOC/MAXLOC/M
--- Comment #7 from domob at gcc dot gnu dot org 2010-02-09 07:30 ---
Fixed (cleared the documentation), but of course the missing support for
CHARACTER arguments is still not fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from domob at gcc dot gnu dot org 2010-02-09 07:28 ---
Subject: Bug 41507
Author: domob
Date: Tue Feb 9 07:27:47 2010
New Revision: 156618
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156618
Log:
2010-02-09 Daniel Kraft
PR fortran/41507
* in
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
|
--- Comment #10 from spop at gcc dot gnu dot org 2010-02-09 06:00 ---
Note that subtracting 1 from the cost of the candidate IV works as well for
this PR's testcase and we generate this asm with the patch:
.file "pr40886.c"
.text
.p2align 4,,15
.globl main
compiler version: gcc 4.0.0, g++ 4.0.0
Reading specs from /usr/bin/../lib/gcc/powerpc-linux/4.0.0/specs
Target: powerpc-linux
Configured with:
/opt/eldk/build/ppc-2007-01-19/work/usr/src/denx/BUILD/crosstool-0.35/build/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux/gcc-4.0.0/configure
--target=powerpc-li
When generating 64-bit code, stack slots allocated to
local variables can overlap alloca areas.
This bug may be specific to PIC code generation since the
test case I have (elf/dl-fini.c in GLIBC) is built with -fPIC.
I'm still trying to distill a small test case and, whether I
can or not, I'll at
--- Comment #9 from spop at gcc dot gnu dot org 2010-02-09 04:57 ---
Hi,
As suggested by Zdenek, here is a patch that lowers the cost of the IV when
it is compared against zero in a condition. The fragile part of this patch is
that it
lowers the cost by a magical constant "10". Would
--- Comment #21 from bkoz at gcc dot gnu dot org 2010-02-09 04:50 ---
Subject: Bug 42460
Author: bkoz
Date: Tue Feb 9 04:49:49 2010
New Revision: 156617
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156617
Log:
2010-02-08 Benjamin Kosnik
PR libstdc++/42460
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-02-09 03:41
---
I was being a bit too aggressive. The following patch fixes it. The problem
does not exist on fortran-exp. I removed my original patch from the branch
since handling of constructors is being revamped completely.
--- Comment #4 from gary at intrepid dot com 2010-02-08 23:11 ---
Created an attachment (id=19827)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19827&action=view)
Log excerpts of parallel make install failures
Excerpts from parallel install (ie, "make -j6 install") failures. Eac
--- Comment #22 from pinskia at gcc dot gnu dot org 2010-02-08 22:36
---
*** Bug 43003 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-08 22:36 ---
Yep in fact the fix for PR 42898 fixed this one also.
*** This bug has been marked as a duplicate of 42898 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-08 22:32 ---
I think this is an issue with volatile really. Which was just fixed in the
last week or so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43003
The following C function:
typedef struct {
unsignedx : 1,
y : 1,
z : 1,
a : 3,
b : 18,
c : 5;
} FOO;
extern volatile FOO var;
voidbar( void )
{
FOO x;
x.x = 1;
x.y = 0;
x.z = 1;
x.a = 0;
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-08 22:16 ---
Right then, sorry for the noise :-)
I hope someone will be kind enough to add those test cases to trunk, too...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from drow at gcc dot gnu dot org 2010-02-08 22:14 ---
With -fmloat-abi=softfp, it looks to me like this is vectorized correctly on
trunk. It's a little unintuitive because it becomes a left vector shift by
"249" == -7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #9 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-08
21:44 ---
The problem is not in specs it is in cc1 (core dump included).
(gdb) bt
#0 0xb788d424 in __kernel_vsyscall ()
#1 0xb76b7350 in raise () from /lib/libc.so.6
#2 0xb76b8b88 in abort () from /lib/libc.s
--- Comment #2 from zsojka at seznam dot cz 2010-02-08 21:37 ---
Created an attachment (id=19826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19826&action=view)
original, unreduced testcase
Preprocessed gcc/fold-const.c - this problem blocks bootstrap with
BOOT_CFLAGS="-O2 -fwra
--- Comment #1 from zsojka at seznam dot cz 2010-02-08 21:35 ---
Created an attachment (id=19825)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19825&action=view)
reduced testcase
While this may look artificial, it was reduced from gcc/fold-const.c
--
http://gcc.gnu.org/bugzi
Command line:
gcc -O2 -fwrapv -Wall -c testcase.c
or
gcc -O3 -fwrapv -Wall -c testcase.c
Tested revisions:
trunk r156604 - warns
trunk r153685 - warns
4.4 r156256 - silent
4.4.2 (gentoo) - silent
4.3.4 (gentoo) - silent
Output:
$ gcc-4.5.0-alpha20100204 -O2 -fwrapv -Wall -c testcase.c
testcase.c:
--- Comment #3 from sezeroz at gmail dot com 2010-02-08 21:18 ---
(In reply to comment #2)
> > FAIL: gcc.c-torture/compile/pr42705.c -O1 (internal compiler error)
> > FAIL: gcc.c-torture/compile/pr42705.c -O1 (test for excess errors)
> > FAIL: gcc.c-torture/compile/pr42705.c -O2 (i
--- Comment #6 from janis at gcc dot gnu dot org 2010-02-08 21:13 ---
Fixed by the patch in comment #5.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from dominiq at lps dot ens dot fr 2010-02-08 20:53 ---
Created an attachment (id=19824)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19824&action=view)
Second test giving a segmentation fault with the patch applied to fortran-dev
--
http://gcc.gnu.org/bugzil
--- Comment #14 from dominiq at lps dot ens dot fr 2010-02-08 20:52 ---
Created an attachment (id=19823)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19823&action=view)
First test giving a segmentation fault with the patch applied to fortran-dev
--
http://gcc.gnu.org/bugzilla
--- Comment #13 from dominiq at lps dot ens dot fr 2010-02-08 20:49 ---
I have applied the patch to a clean trunk at revision 156605 and the test
compiles (further tests pending). I have also applied the patch to fortran-dev
at revision 156573 and the compilation gives a segmentation fau
--- Comment #3 from joseph at codesourcery dot com 2010-02-08 20:40 ---
Subject: Re: Missed vectorization on ARM NEON
On Mon, 8 Feb 2010, pinskia at gcc dot gnu dot org wrote:
> > Try adding -mfloat-abi=softfp to make the compiler actually consider using
> > NEON (needed at least for
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-08 20:32 ---
> Try adding -mfloat-abi=softfp to make the compiler actually consider using
> NEON (needed at least for arm-eabi, I don't know about arm-elf).
I don't think that is needed any more since the addition of the hard fl
--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-02-08 20:31 ---
Created an attachment (id=19822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19822&action=view)
Extra vectorization tests
Try adding -mfloat-abi=softfp to make the compiler actually consider using
NEON (needed
Hello,
In late 2008 there was a post about a wrong-code bug on hardwarebug.org
(http://hardwarebug.org/2008/11/28/codesourcery-fails-again/#more-83). There
was this test case, and it was not vectorized correctly.
---
extern unsigned char dst[512] __attribute__((aligned(8)));
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-08 18:45 ---
FWIW, bootstrap+regtest succeeds on ia64-unknown-linux-gnu with the patch set
applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42617
--- Comment #5 from pault at gcc dot gnu dot org 2010-02-08 18:19 ---
Please excuse the lack of a diff - I was using a snap shot to work on this PR.
This fixes the problem but I do not know if it regtests; however, I believe it
to be good. If somebody wants to take it to completion, pl
--- Comment #3 from rwild at gcc dot gnu dot org 2010-02-08 18:18 ---
Can you make a bit more of the output of such a failed install available,
say, about 50 lines around each of the two different failures?
Wrt. the failure with headers, it seems GNU coreutils install does not
allow con
--- Comment #12 from pault at gcc dot gnu dot org 2010-02-08 17:25 ---
(In reply to comment #11)
> (In reply to comment #10)
> > This was followed by http://gcc.gnu.org/ml/fortran/2009-12/msg00166.html
>
> I have just retested your patch on a clean tree to Dominique's testcase, but I
>
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42999
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-02-08 16:50
---
Best to do it post RA, so that we can issue the best sequences of insns. I
have some better sequences that could be generated for Thumb2 which would avoid
the need for an IT instruction in many cases.
--
http
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-08 16:49 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
It miscompiles
if (need <= i) {
in filterstring inlined to builtin_filter in Python/bltinmodule.c.
Testcase:
int __attribute__((noinline))
foo (long i, long j)
{
if (i >= 1)
if (j > -9223372036854775807L)
{
long x;
j--;
x = i +
--- Comment #11 from steven at gcc dot gnu dot org 2010-02-08 16:45 ---
Trunk today (r156595) optimizes this at -O1, -Os, and -O2 in the tree
optimizers. The .fre pass removes the first func call, then .dom1 removes the
next two. The .dom2 pass removes the remaining one.
If I add anothe
--- Comment #9 from rearnsha at arm dot com 2010-02-08 16:31 ---
Subject: Re: [arm] Combine cannot do its job because
immediate operand is used instead of register
On Mon, 2010-02-08 at 16:30 +, rearnsha at arm dot com wrote:
> mov r1, r5, r4, lsr #8
>
Should
--- Comment #8 from rearnsha at arm dot com 2010-02-08 16:30 ---
Subject: Re: [arm] Combine cannot do its job because
immediate operand is used instead of register
On Mon, 2010-02-08 at 16:11 +, steven at gcc dot gnu dot org wrote:
> Can someone please explain what the exp
--- Comment #6 from steven at gcc dot gnu dot org 2010-02-08 16:27 ---
Must be a regression from some version, if POINTER_PLUS_EXPR is the reason for
this extra NEG. Matz knows TER best these days, so matz -> cc.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from steven at gcc dot gnu dot org 2010-02-08 16:11 ---
New test case is with func defined extern, as already mentioned in comment #5:
extern void func(char c, int t);
void foo(int u)
{
func ( 8, (u >> 24) & 0xffL );
func ( 8, (u >> 16) & 0xffL );
func ( 8, (u >> 8
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-08 15:54 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2010-02-08 15:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from jakub at gcc dot gnu dot org 2010-02-08 15:51 ---
Subject: Bug 42890
Author: jakub
Date: Mon Feb 8 15:50:59 2010
New Revision: 156605
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156605
Log:
PR tree-optimization/42890
* tree-inline.c (delet
--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-08 15:49 ---
Subject: Bug 42890
Author: jakub
Date: Mon Feb 8 15:49:30 2010
New Revision: 156604
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156604
Log:
PR tree-optimization/42890
* g++.dg/torture/pr428
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-08 15:48 ---
Subject: Bug 42931
Author: jakub
Date: Mon Feb 8 15:48:01 2010
New Revision: 156603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156603
Log:
PR tree-optimization/42931
* tree-loop-linear.c (
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-08 15:47 ---
Subject: Bug 42931
Author: jakub
Date: Mon Feb 8 15:47:01 2010
New Revision: 156602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156602
Log:
PR tree-optimization/42931
* tree-loop-linear.c (
--- Comment #2 from zsojka at seznam dot cz 2010-02-08 15:28 ---
I can reproduce this on x86_64, trunk r156598 and 4.4 r156256.
Also, bootstrap fails for me with BOOT_CFLAGS="-O2 -ftree-loop-distribution":
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1
--- Comment #18 from paolo dot carlini at oracle dot com 2010-02-08 15:27
---
It is available, for sure. We are talking about trying to use the feature in a
case where the code is actually ill-formed, per a DR which is in the [Ready]
status, that is, a very advanced status, but still no
--- Comment #17 from lavock at gmail dot com 2010-02-08 15:18 ---
(In reply to comment #16)
> Yes, but you're using an experimental implementation of an incomplete
> specification. Using it for serious code would be foolish, so I tend to agree
> it's low priority
Yes, i agree with low
--- Comment #16 from jwakely dot gcc at gmail dot com 2010-02-08 15:10
---
(In reply to comment #15)
> Destroying an object from a base class pointer whose destructor is not virtual
> is an undefined behaviour according to the standard. I tend to think that
> silently removing the virut
--- Comment #2 from dominiq at lps dot ens dot fr 2010-02-08 15:02 ---
The code compiles also with fortran-exp revision 156589.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42999
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-08 15:01 ---
I think it regressed between 2010-01-07-r155688 and 2010-01-10-r155780
Jerry, I think that is due to your initializer patch:
r155769 | jvdelisle | 2010-01-09 18:47:04 +0100 (Sat, 09 Jan 2010) | 18 lines
http://gcc.g
--- Comment #2 from jan dot kratochvil at redhat dot com 2010-02-08 14:59
---
Sorry, I agree now this Bug is invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42939
--- Comment #5 from hubicka at ucw dot cz 2010-02-08 14:59 ---
Subject: Re: [4.4 Regression] Crash in
type_like_member_ptr_p in ipa-prop.c:382
> The trunk has delete_unreachable_blocks_update_callgraph, perhaps we want
> something like that for the branch as well. As delete_un
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.4.2
Target Mil
This could should compile, I believe
TYPE DD
INTEGER :: I
END TYPE DD
TYPE(DD) :: X(2)=(/(DD(I),I=1,2)/)
END
but does not with current 4.5 trunk, fails with:
Error: Parameter 'i' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
--
--- Comment #15 from albrt2000 at gmail dot com 2010-02-08 14:49 ---
(In reply to comment #14)
> Basing on Core 906, seems rather straightforward that the snippet is
> ill-formed, the only problem is that neither 4.4 nor current mainline reject
> it.
That's also should be the case for n
--- Comment #9 from burnus at gcc dot gnu dot org 2010-02-08 14:47 ---
Regarding 4.4: It fails here (x86-64) for any option for:
IF (ANY (T1%I .NE. [999, 2, 999, 4])) CALL ABORT
as the result is:[1, 999, 3, 999]. (The other check succeeds.)
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #9 from jakub at gcc dot gnu dot org 2010-02-08 14:40 ---
The testcase fails on the 4.4 branch, as -fipa-sra isn't a valid option there.
H.J., can you please before committing testsuite backports at least run make
check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
--- Comment #7 from jakub at gcc dot gnu dot org 2010-02-08 14:38 ---
This ICEs on the 4.4 branch as well (obviously only when configured with
--enable-checking=yes).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jv244 at cam dot ac dot uk 2010-02-08 14:38 ---
(In reply to comment #10)
> This was followed by http://gcc.gnu.org/ml/fortran/2009-12/msg00166.html
I have just retested your patch on a clean tree to Dominique's testcase, but I
don't get any segfault, and also valgr
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-08 14:36
---
Basing on Core 906, seems rather straightforward that the snippet is
ill-formed, the only problem is that neither 4.4 nor current mainline reject
it. If that's the complete analysis, the issue is pretty low pr
--- Comment #13 from albrt2000 at gmail dot com 2010-02-08 14:25 ---
>
> struct A {
> virtual ~A();
> };
>
> A::~A() = default;
>
> I think this should be OK (but maybe not in GCC 4.4 only in 4.5)
>
This already works in gcc 4.4.1 that I use.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #12 from albrt2000 at gmail dot com 2010-02-08 14:24 ---
Ok. So, gcc is conformant with the document you mentioned. I am reporting this
discussion in comp.std.c++ since it makes me think that this behaviour reduces
one of the interest of the default declaration.
--
http:
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-08 14:11 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-08 14:10 ---
Subject: Bug 42995
Author: rguenth
Date: Mon Feb 8 14:10:15 2010
New Revision: 156601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156601
Log:
2010-02-08 Richard Guenther
PR middle-end/42995
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-08 14:10 ---
Subject: Bug 42462
Author: rguenth
Date: Mon Feb 8 14:10:15 2010
New Revision: 156601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156601
Log:
2010-02-08 Richard Guenther
PR middle-end/42995
--- Comment #10 from pault at gcc dot gnu dot org 2010-02-08 14:06 ---
(In reply to comment #9)
> For reference, this was Paul's message to the list:
>
> http://gcc.gnu.org/ml/fortran/2009-12/msg00164.html
>
Dear Joost,
This was followed by http://gcc.gnu.org/ml/fortran/2009-12/msg0
--- Comment #11 from jwakely dot gcc at gmail dot com 2010-02-08 14:04
---
(In reply to comment #9)
> I'm not sure to understand your last comment (sorry I 'm not a natural english
> speaker). Do you mean that virtual ~A() = default; should be an error ? If we
Yes. GCC implements the
--- Comment #10 from jwakely dot gcc at gmail dot com 2010-02-08 14:00
---
(In reply to comment #7)
>
> There is a thread in comp.std.c++ about this.
Yes, but I don't think anyone's mentioned core issue 906, which makes all the
arguments rather moot. Read that resolution, not n3000.
--- Comment #9 from albrt2000 at gmail dot com 2010-02-08 13:58 ---
(In reply to comment #6)
> Interesting. Thus I get Core 906 [Ready] as meaning that this snippet is just
> illegal, and should be rejected, in other terms, this is an accept invalid,
> right?
>
Hi,
I'm not sure to under
--- Comment #8 from jwakely dot gcc at gmail dot com 2010-02-08 13:56
---
(In reply to comment #6)
> Interesting. Thus I get Core 906 [Ready] as meaning that this snippet is just
> illegal, and should be rejected, in other terms, this is an accept invalid,
> right?
>
Yes, I believe 4.
--- Comment #4 from David dot Biesack at sas dot com 2010-02-08 13:54
---
Created an attachment (id=19821)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19821&action=view)
build log showing failure (configured with --disable-bootstrap)
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #3 from David dot Biesack at sas dot com 2010-02-08 13:52
---
Pretty much the same result.
I did
make dist-clean
mkdir Linux-x64
cd Linux-x64
../configure -with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
and it still failed wit similar errors trying t
--- Comment #2 from hjl dot tools at gmail dot com 2010-02-08 13:51 ---
(In reply to comment #0)
> Running target unix/
> FAIL: gcc.c-torture/compile/pr42632.c -O2 (test for excess errors)
> FAIL: gcc.c-torture/compile/pr42632.c -O3 -fomit-frame-pointer (test for
> exces
> s errors)
--- Comment #7 from lavock at gmail dot com 2010-02-08 13:49 ---
(In reply to comment #5)
> n3000 says "Only special member functions may be explicitly defaulted, and the
> implementation shall define them as if they had implicit definitions."
>
> An implicit destructor is not virtual.
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-08 13:33 ---
void foo(void *);
void bar(void *);
void ndisc_fill_addr_option(unsigned char *opt, int data_len,
unsigned short addr_type)
{
int pad;
if (addr_type == 32)
pad = 2;
else
pad
--- Comment #21 from jamborm at gcc dot gnu dot org 2010-02-08 13:31
---
The testcase now passes. The issue is fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from jamborm at gcc dot gnu dot org 2010-02-08 13:24
---
Subject: Bug 42898
Author: jamborm
Date: Mon Feb 8 13:24:12 2010
New Revision: 156599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156599
Log:
2010-02-08 Martin Jambor
PR middle-end/42898
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-08 13:19 ---
Confirm - I get for "./a.out test" the following result.
Current (gfortran):
With no value, length was:4 and status:0
With LEN=1 value, length was:1 and status:-1 < Bad: len = 1
With LEN=10 value, length
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-08 13:14 ---
Confirmed. PRE does this - reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from bero at arklinux dot org 2010-02-08 13:00 ---
Only happens at -O2 and higher
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42998
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-08 12:57
---
Interesting. Thus I get Core 906 [Ready] as meaning that this snippet is just
illegal, and should be rejected, in other terms, this is an accept invalid,
right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-08 12:49 ---
The duplication of sp in r4 is tracked in a separate bug report, bug 42500.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-02-08 12:35
---
n3000 says "Only special member functions may be explicitly defaulted, and the
implementation shall define them as if they had implicit definitions."
An implicit destructor is not virtual.
http://www.open-std.or
--- Comment #1 from bero at arklinux dot org 2010-02-08 12:29 ---
Created an attachment (id=19820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19820&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42998
Building Linux kernel 2.6.33-rc7 with gcc 4.5-svn fails with an ICE:
net/ipv6/ndisc.c: In function 'ndisc_fill_addr_option':
net/ipv6/ndisc.c:199:12: error: type mismatch in pointer plus expression
u8 *
void *
unsigned int
pretmp.191_160 = D.41953_14 + 2;
net/ipv6/ndisc.c:199:12: internal comp
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-08 12:14 ---
Richard, can we split thumb2_compare_scc? If so, when/how would you do this?
(I'm thinking of a post-RA splitter, but perhaps it could be done earlier.)
--
steven at gcc dot gnu dot org changed:
What
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-08 12:13 ---
I believe the problem is that cgraph edges aren't updated during
tree_function_versioning's call to delete_unreachable_blocks:
if (gimple_in_ssa_p (cfun))
{
free_dominance_info (CDI_DOMINATORS);
free_
--- Comment #3 from dibeas at ieee dot org 2010-02-08 12:11 ---
Also related: dereferencing a data member pointer with an lvalue incorrectly
yields an lvalue:
struct X { int x; };
X f();
void g() {
int X::*ptr = &X::x;
f().*ptr = 5; // should not compile!
}
--
dibeas at
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-08 12:01 ---
Which is a remainder that devs should enable checking when testing patches for
branches ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42997
Running target unix/
FAIL: gcc.c-torture/compile/pr42632.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/pr42632.c -O3 -fomit-frame-pointer (test for
exces
s errors)
FAIL: gcc.c-torture/compile/pr42632.c -O3 -g (test for excess errors)
FAIL: gcc.c-torture/compile/pr42632.c -Os (t
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.5 |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-08 11:29 ---
Trunk today (r156595) produces this:
repl1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
mov r4, r0
mov r1, #0
--- Comment #7 from rearnsha at gcc dot gnu dot org 2010-02-08 11:26
---
(In reply to comment #6)
> Does the ARM backend already support conditional compares?
>
Yes, but only by manipulating store-flag sequences in the combine pass. That's
a poor-man's implementation and it can lead
1 - 100 of 116 matches
Mail list logo
