--- Comment #9 from jv244 at cam dot ac dot uk 2010-02-08 08:09 ---
(In reply to comment #8)
> Happens a lot in 465.tonto btw.
I had tested Paul's patch on CP2K, where it reduces the calls to
gfortran_internal[un]pack from 4252 to 1276. I think it addresses an issue that
is quite import
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-08 08:51 ---
This is completely intentional.
The intent is to differentiate between debug info at the call insn in the
caller and when inside the call. At the call insn various var locations can be
still live (e.g. call clobbered
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-08 10:19 ---
It doesn't inline it because:
Considering inline candidate get_data_for.
Not inlining: code size would grow by 3 insns.
The callee is estimated to have size 16 while the call costs less. The issue
is a missing che
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-08 10:41 ---
Subject: Bug 42995
Author: rguenth
Date: Mon Feb 8 10:41:25 2010
New Revision: 156598
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156598
Log:
2010-02-08 Richard Guenther
PR middle-end/42995
According to the F2003 standard, the LENGTH argument does "not consider any
possible truncation or padding in assigning the command argument value to the
VALUE argument" (13.7.42). However, gfortran appears to use the minimum of the
length of the VALUE argument (if present) and the length of the c
"GCC: (GNU) 4.5.0 20100208 (experimental) [trunk revision
156595]"
Questions for those who know ARM:
* What is the purpose of insn 12 here? It looks to me like this is dead code,
since r5 is restored in insn 38 (although, not knowing ARM so well, I may be
wrong).
* After combine we have the
--- Comment #1 from ian_harvey at bigpond dot com 2010-02-08 10:48 ---
Created an attachment (id=19819)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19819&action=view)
Simple test case
Call the resulting program with an argument longer than one character.
--
http://gcc.gnu.o
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-08 10:51 ---
Add an ARM guy to the CC:
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-08 11:07
---
Can be closed (of course std::is_convertible needs front-end support, but
that's another story)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-08 11:08
---
DR 585 has been resolved to NAD
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
@ sp needed for prologue
pop {pc}
.size test, .-test
.ident "GCC: (GNU) 4.5.0 20100208 (experimental) [trunk revision
156595]"
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from steven at gcc dot gnu dot org 2010-02-08 11:18 ---
Does the ARM backend already support conditional compares?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11831
--- Comment #16 from paolo dot carlini at oracle dot com 2010-02-08 11:19
---
Can we review this issue? Two comments: 1- Now I can see only dynamic memory
allocations via new / delete everywhere, thus, no __builtin_alloca; 2- *If* one
really wanted to use VLAs, now it should be possible
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-08 11:22 ---
Patch of comment #3 from Ramana was never committed to the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from paolo dot carlini at oracle dot com 2010-02-08 11:24
---
Is this still an issue? To be honest I have no idea if this target is still in
good shape or not...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- 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
--- 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
--
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
--
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
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
--- 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
--- 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 #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 #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
--
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
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
--- 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
--- 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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
--
--
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
--- 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
--- 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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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
--
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 #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
>
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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
1 - 100 of 116 matches
Mail list logo
