On Thu, Mar 18, 2010 at 12:34 AM, Ian Lance Taylor i...@google.com wrote:
Paulo J. Matos pocma...@gmail.com writes:
Thank you for the help regarding usage of libgcc.
- For floating point emulation, how does gcc know that the arch needs
floating point emulation or not? Does it depend on the
On Wed, Mar 17, 2010 at 11:38 PM, Paulo J. Matos pocma...@gmail.com wrote:
Gcc 4.3.4 is generating a call to floatunsihf, which not only I can't
find in libgcc but it also doesn't show in the internal docs.
My guess is that this name is generated automatically and reveals some
mistake in my
On Thu, Mar 18, 2010 at 6:51 AM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Mar 17, 2010 at 11:38 PM, Paulo J. Matos pocma...@gmail.com wrote:
I cannot remember when half
float support came in though, I thought it was only added on the trunk
or did you backport that support too.
Thanks
On Wed, Mar 17, 2010 at 3:35 PM, Paulo J. Matos pocma...@gmail.com wrote:
So, let me see if I got this write.
This is not meant as a spam mail but I can't help myself to correct
this horrible mistake. Obviously I meant right, instead of write.
:)
[Having this error spread across multiple mailing
On 03/18/2010 05:22 AM, Jae Hyuk Kwak wrote:
On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
Note, that many hash tables are computed by the modulus operation, which is
often fairly expensive (and on machines without a hardware divide unit,
requiring a
The reasoning here is
that if splitting will result in worse code, then we shouldn't have
accepted it in the first place. If dropping this alternative results in
register allocator failures for some strange reason, then we accept it
and generate the 3 instruction sequence with a new
I've reported here recently about gcc producing conditional branches
with static outcome. I've finally managed to produce a simple
self-contained example. Here it is:
int f()
{
static int LSW=-1;
double x=0.987654321;
unsigned char ix = *((char *)x);
if(ix==0xdd || ix==0x3f)
It could be very very useful to add tatic Stack Usage Analysis for C/C
++. Something like -fstack-usage already done in gnat
thanks
Hi,
In my backend, I have a problem with the pass which determines the
best register class for a virtual register (Pass 0 for finding allocno
costs).
In all insns in this example both R_REGS and D_REGS register classes
are applicable (but all registers in an insn should be from the same
register
Ok. Thanks!
Then I will persuade the guys who develop the MCU to add one or more
base registers to ease the reload problem, and besides, I will add
some virtual registers( who are static memory.) to hold 16,32 bit
mode variables.Hope these 2 solutions can make better codes. Now I
just begin to
On 2010-03-16 16:18:17 +0100, Richard Guenther wrote:
pow (a, 0.5) is always expanded to sqrt(a).
This violates the ISO C99 standard for -0.0.
According to N1256, F.9.4.4:
pow(±0, y) returns +0 for y 0 and not an odd integer.
So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should
The problem I see is that for registers 100,101 I get best register
class D instead of R - actually they get the same cost and D is chosen
(maybe because it is first).
Hi Frank.
Do D and R overlap? It would be useful to know which regs are in
which class, before trying to understand what is
On 2010-03-18 14:43:39 +0100, Vincent Lefevre wrote:
This violates the ISO C99 standard for -0.0.
According to N1256, F.9.4.4:
pow(±0, y) returns +0 for y 0 and not an odd integer.
So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
according to the IEEE 754 standard
-- Forwarded message --
From: Frank Isamov frank.isa...@gmail.com
Date: Thu, Mar 18, 2010 at 4:28 PM
Subject: Re: Coloring problem - Pass 0 for finding allocno costs
To: Ian Bolton bol...@icerasemi.com
On Thu, Mar 18, 2010 at 3:51 PM, Ian Bolton bol...@icerasemi.com wrote:
The
Hi,
On Thu, 18 Mar 2010, Vincent Lefevre wrote:
On 2010-03-16 16:18:17 +0100, Richard Guenther wrote:
pow (a, 0.5) is always expanded to sqrt(a).
This violates the ISO C99 standard for -0.0.
According to N1256, F.9.4.4:
pow(±0, y) returns +0 for y 0 and not an odd integer.
So,
-Original Message-
From: Frank Isamov [mailto:frank.isa...@gmail.com]
Sent: 18 March 2010 14:29
To: Ian Bolton
Subject: Re: Coloring problem - Pass 0 for finding allocno costs
On Thu, Mar 18, 2010 at 3:51 PM, Ian Bolton bol...@icerasemi.com
wrote:
The problem I see is that for
May I remind my original question:
In the block Handle constant exponents. in gcc/builtins.c, the condition
!optimize_size has been replaced with optimize_insn_for_speed_p () between
gcc 4.3 and 4.4, but I have not been able to find when and why.
Does anybody remembers the when and why?
This
On Thu, Mar 18, 2010 at 04:07:28PM +0100, Dominique Dhumieres wrote:
May I remind my original question:
In the block Handle constant exponents. in gcc/builtins.c, the condition
!optimize_size has been replaced with optimize_insn_for_speed_p () between
gcc 4.3 and 4.4, but I have not been
Hi,
On Thu, 18 Mar 2010, Frank Isamov wrote:
From the h file:
#define REG_CLASS_CONTENTS \
{
\
{0x, 0x, 0x}, /* NO_REGS*/ \
{0x, 0x, 0x}, /* D_REGS*/ \
On Wed, 17 Mar 2010, Jakub Jelinek wrote:
On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote:
That will very much pessimize debug info. While we are now always in
-funit-at-a-time mode, that doesn't mean DECL_RTL is computed early enough.
From the file scope non-static vars, at
Hi,
I am trying to implement a simple load 8 bytes instruction.
I tried to use movdi so that it would allocate two sequential
registers for the load.
It starts well but in pass subreg1 the insns are decomposed and all DI
operands are replaced with SI.
I understand that this is a desireable
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Michael Matz
Sent: 18 March 2010 15:13
To: Frank Isamov
Cc: gcc@gcc.gnu.org
Subject: Re: Coloring problem - Pass 0 for finding allocno costs
Hi,
On Thu, 18 Mar 2010, Frank Isamov wrote:
On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
according to the IEEE 754 standard (and F.9.4.5 from ISO C99).
Yes, and I don't know why they specified it like that. After all
(-0)*(-0)==+0 (not ==-0), so the above
On Thu, Mar 18, 2010 at 04:34:56PM +0100, Vincent Lefevre wrote:
On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
But unfortunately you are right, this expansion can only be done for
-fno-signed-zeros. (FWIW the general expandsion of pow(x,N/2) where
N!=1 is already guarded by unsafe_math,
On Thu, 18 Mar 2010, Vincent Lefevre wrote:
On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
according to the IEEE 754 standard (and F.9.4.5 from ISO C99).
Yes, and I don't know why they specified it like that.
On Thu, Mar 18, 2010 at 12:23 PM, Alain Ketterlin
alain.ketter...@gmail.com wrote:
I've reported here recently about gcc producing conditional branches
with static outcome. I've finally managed to produce a simple
self-contained example. Here it is:
int f()
{
static int LSW=-1;
On Thu, Mar 18, 2010 at 04:25:03PM +0100, Richard Guenther wrote:
On Wed, 17 Mar 2010, Jakub Jelinek wrote:
On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote:
That will very much pessimize debug info. While we are now always in
-funit-at-a-time mode, that doesn't mean
On 2010-03-18 15:49:05 +, Joseph S. Myers wrote:
And the same rule on pow(-0, y) is present in 754-2008 (I don't know
whether this was deliberately following the C definition, or deciding
independently that this was the right definition, but you may know as a
listed member of the
On Thu, Mar 18, 2010 at 2:30 AM, Jim Wilson wil...@codesourcery.com wrote:
On Wed, 2010-03-17 at 11:27 +0800, fanqifei wrote:
You are correct. The reload pass emitted the clr.w insn.
However, I can see loop opt passes after reload:
problem1.c.174r.loop2_invariant1
Not unless you have a
Paulo J. Matos pocma...@gmail.com writes:
On Thu, Mar 18, 2010 at 6:51 AM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Mar 17, 2010 at 11:38 PM, Paulo J. Matos pocma...@gmail.com wrote:
I cannot remember when half
float support came in though, I thought it was only added on the trunk
or
Google is your friend...
Thanks Jack. As you can see in comment #46 of pr40106, I have found
my own way. In my previous attempts I have made two mistakes:
(1) I tried to use the search engine of the gcc mailing lists that
kept parsing optimize_insn_for_speed_p as if the _ were spaces.
(2) I did
This is the beta release of binutils 2.20.51.0.7 for Linux, which is
based on binutils 2010 0318 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Thu, 2010-03-18 at 19:20 +0800, Amker.Cheng wrote:
Does it possible that the method would ever result in register
allocator failure?
In my understanding, doesn't reload pass would do whatever it can to make
all insns' constraints satisfied?
In theory, there should be no failure. In
Snapshot gcc-4.5-20100318 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100318/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hi Michael,
Thank you for the details.
On Thu, Mar 18, 2010 at 8:17 AM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
Note, that many hash tables are computed by the modulus operation, which is
often fairly expensive (and on machines without a hardware divide unit,
requiring a
You said you would fix this several nights ago, but I still
haven't seen any changes to fixincludes since then.
When will you get around to fixing these regressions you
introduced?
Thank you.
I found a bug of ICE in gcc-4.4.3 on sh-elf.
gcc-4.3 and gcc-4.5 does not have this problem.
$ gcc -O2 mtest01-k-e.c
mtest01-k.c: In function emainf:
mtest01-k.c:88: error: could not split insn
(jump_insn 312 302 472 mtest01-k.c:64 (parallel [
(set (pc)
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-18 07:16 ---
BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a
PARALLEL with what the insn really does and checking that in the match_parallel
predicate probably wouldn't clash with anything else. If
--- Comment #1 from iwamatsu at nigauri dot org 2010-03-18 07:18 ---
Created an attachment (id=20138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20138action=view)
The source code that can reproduce a problem.
this code generate by -E option.
Sorry. There is the code to
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-18 08:27 ---
Reopening...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2010-03-18 08:29 ---
...to close as dup of bug 39871
*** This bug has been marked as a duplicate of 39871 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from steven at gcc dot gnu dot org 2010-03-18 08:29 ---
*** Bug 43286 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from steven at gcc dot gnu dot org 2010-03-18 08:31 ---
In the test case from bug 43286, should_replace_address does not perform the
following replacement because the address cost is the same and the replacement
is only done if new_rtx is more expensive than old_rtx.
--- Comment #8 from ramana at gcc dot gnu dot org 2010-03-18 09:25 ---
(In reply to comment #7)
BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a
PARALLEL with what the insn really does and checking that in the
match_parallel
predicate probably wouldn't
--- Comment #9 from ramana at gcc dot gnu dot org 2010-03-18 10:21 ---
Created an attachment (id=20139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20139action=view)
patch
Patch that makes the ICE disappear by converting these into mem:BLKmode
(pre_modify (Pmode)). I will submit
during make:
./prev-gcc/g++ ... -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Icp
.../gcc/cp/parser.c -o cp/parser.o
error: converting false to
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-18 10:59
---
Can you try replacing it with NULL_TREE? If everything goes well on your end,
we can commit the fix as obvious (I'm going to sanity check it for a normal
build)
--
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-03-18 11:30
---
Confirming. 4.5 trunk needs lots of memory in PRE.
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ailin dot nemui at gmail dot com 2010-03-18 11:37
---
works fine :) thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43418
--- Comment #3 from paolo at gcc dot gnu dot org 2010-03-18 11:46 ---
Subject: Bug 43418
Author: paolo
Date: Thu Mar 18 11:46:15 2010
New Revision: 157536
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157536
Log:
2010-03-18 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #4 from paolo at gcc dot gnu dot org 2010-03-18 11:46 ---
Subject: Bug 43418
Author: paolo
Date: Thu Mar 18 11:46:33 2010
New Revision: 157537
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157537
Log:
2010-03-18 Paolo Carlini paolo.carl...@oracle.com
PR
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #5 from paolo dot carlini at oracle dot com 2010-03-18 11:47
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-18 12:21 ---
Subject: Bug 43402
Author: matz
Date: Thu Mar 18 12:20:50 2010
New Revision: 157538
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157538
Log:
PR tree-optimization/43402
* tree-cfgcleanup.c
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-03-18 12:39 ---
Looks the same issue in
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00747.html
though I can't reproduce the problem with my gcc-4.4.3 and
4.4 head compilers for the test case in #1.
Could you try the patch in the
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-18 12:46 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from dodji at gcc dot gnu dot org 2010-03-18 12:50 ---
Things have changed quite a bit in GCC 4.5 (trunk).
Now for the code:
class C
{
static const int foo;
};
int
main()
{
return 0;
}
GCC 4.5 will not generate any debug info for the class C at all, because it's
--- Comment #8 from dodji at gcc dot gnu dot org 2010-03-18 12:52 ---
Bug no more present in GCC 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #10 from dodji at gcc dot gnu dot org 2010-03-18 12:53 ---
Bug no more present in 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hjl at gcc dot gnu dot org 2010-03-18 13:11 ---
Subject: Bug 43360
Author: hjl
Date: Thu Mar 18 13:10:49 2010
New Revision: 157539
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157539
Log:
Remove the REG_EQUAL note if we don't know its invariant status.
--- Comment #16 from hjl at gcc dot gnu dot org 2010-03-18 13:13 ---
Subject: Bug 43360
Author: hjl
Date: Thu Mar 18 13:13:42 2010
New Revision: 157540
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157540
Log:
Remove the REG_EQUAL note if we don't know its invariant status.
--- Comment #17 from hjl at gcc dot gnu dot org 2010-03-18 13:15 ---
Subject: Bug 43360
Author: hjl
Date: Thu Mar 18 13:15:21 2010
New Revision: 157541
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157541
Log:
Remove the REG_EQUAL note if we don't know its invariant status.
--- Comment #18 from hjl dot tools at gmail dot com 2010-03-18 13:16
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #19 from steven at gcc dot gnu dot org 2010-03-18 13:20 ---
For the record: bootstrapped+tested on amd64-linux and ia64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot
|dot org
gcc replaces pow(x, 0.5) by sqrt(x). This is invalid when x is -0. Indeed,
according to ISO C99 (N1256), F.9.4.4:
pow(±0, y) returns +0 for y 0 and not an odd integer.
So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0 according
to the IEEE 754 standard (and F.9.4.5 from ISO
on line 6197 to 6205:
unsigned char buf[5];
unsigned int i, len;
unsigned long offset;
for (i = 0; i 9; i++)
{
GET_OP (buf[i]);
if ((buf[i] 0x80) == 0)
break;
}
An obviously small wrong
--- Comment #1 from vincent at vinc17 dot org 2010-03-18 14:33 ---
If I understand correctly, the bug appears with:
r119248 | rguenth | 2006-11-27 12:38:42 +0100 (Mon, 27 Nov 2006) | 10 lines
2006-11-27 Richard Guenther rguent...@suse.de
PR middle-end/25620
*
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-18 14:35 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #18 from vincent at vinc17 dot org 2010-03-18 14:37 ---
The patch affected C, where the transformation of pow(x, 0.5) into sqrt(x) is
incorrect. See PR 43419.
--
vincent at vinc17 dot org changed:
What|Removed |Added
--- Comment #5 from dodji at gcc dot gnu dot org 2010-03-18 14:38 ---
(In reply to comment #4)
As we discussed on IRC, it seems we'd need a way to express that we'd want the
debugger to create a temporary, initialize it and later destroy it. DWARF can't
express as of now. So we'll
--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-18 14:41 ---
While you are looking at this part, you may have to check that a similar
problem does not exist when converting x*sqrt(x) to pow(w,1.5) and so on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-18 14:48 ---
I checked, and these and similar transformations are always guarded by
flag_unsafe_math_optimizations, so we should be fine, unless I missed a case
of course. If you notice one, please create a bug report.
--
--- Comment #3 from roman at binarylife dot net 2010-03-18 14:52 ---
This looks related.
$ cat test.c
_Decimal64 func() {
return 9e384dd + 9e384dd;
}
$ gcc -c test.c
test.c: In function 'func':
test.c:2:3: internal compiler error: in decimal_to_decnumber, at dfp.c:115
...
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-18 15:29 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-18 15:31 ---
Looks like we need to guard this with HONOR_SIGNED_ZEROS.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Compiling the code below (with -O2 -Wall -std=c99, gcc 4.4.3) gives the warning
apa.c: In function 'f':
cc1: warning: dereferencing pointer '({anonymous})' does break strict-aliasing
rules
apa.c:9: note: initialized from here
which is both unhelpful and dubious - is the code really doing
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:08 ---
Subject: Bug 43419
Author: matz
Date: Thu Mar 18 16:07:53 2010
New Revision: 157543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157543
Log:
PR middle-end/43419
* builtins.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:47 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-18 16:47 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-18 16:48 ---
readelf is not part of the GCC project but the binutils project. Please report
it to them (http://www.sourceware.org/bugzilla/ ).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-18 16:53 ---
That would indeed be my preferred approach. The alternative would be to
add much if (x == error_mark_node) sillyness all over the middle-end, like
the front-ends do. The middle-end should be able to rightfully expect
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-18 16:55 ---
A radical approach would be to not gimplify in case of errors
Part of the problem there is that the C++ front-end (at least used to), produce
errors while gimplifying (though that might be fixed).
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-18 16:57 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24222 for all the bugs about
emitting errors/warnings during gimplification; though as I said some of those
might be fixed; I have not checked yet.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-18 16:59 ---
I will be looking into this, we should be able to not have a function_type with
an error_mark_node as an argument but we should just have an error_mark_node
instead.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-18 17:05 ---
Actually this is a simple patch:
Index: c-decl.c
===
--- c-decl.c(revision 157518)
+++ c-decl.c(working copy)
@@ -6118,6 +6118,7 @@ grokparms
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-18 17:24 ---
I have a patch. It's just unfortunate ordering of phi-translation and missed
caching.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
--- Comment #20 from changpeng dot fang at amd dot com 2010-03-18 17:24
---
(In reply to comment #19)
Splitting critical edges for CDDCE will probably also solve this problem.
Richard.
Yes, splitting critical edges is an enhancement to CDDCE and can solve this
problem. There are
--- Comment #4 from janis at gcc dot gnu dot org 2010-03-18 17:27 ---
The tests also fail on powerpc64-linux, although the first one gets the same
error with and without optimization.
elm3c105% cat 43374-1.c
int func(_Decimal32 v) {
return __builtin_isinf(v);
}
elm3c105%
--- Comment #21 from rguenther at suse dot de 2010-03-18 17:30 ---
Subject: Re: [4.5 Regression] Empty loop not
removed
On Thu, 18 Mar 2010, changpeng dot fang at amd dot com wrote:
--- Comment #20 from changpeng dot fang at amd dot com 2010-03-18 17:24
---
(In reply to
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-03-18 17:37
---
Native functions aren't expected to work with a 'C' body.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-18 17:39 ---
Then it should produce an error and not an internal compiler error.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
gcc could not vectorize this simple reversed loop:
int a[100], b[100];
void foo(int n)
{
int i;
for(i=n-2; i=0; i--)
a[i+1] = a[i] + b[i];
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=2 -c foo.c
foo.c:6: note: not vectorized: complicated access pattern.
foo.c:3: note:
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-18 17:55 ---
Works on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43416
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-18 17:56 ---
Could be a dup of bug 42871 or PR 43074.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43416
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-03-18 17:59
---
All fine again. Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-18 18:00 ---
The following fixes the PR. I have not regtested yet but anticipate that all
will be well.
Index: ../trunk/gcc/fortran/trans-expr.c
===
---
chf...@pathscale:~/gcc$ cat foo.c
int a[100], b[100], c[100];
void foo(int n, int mid)
{
int i;
for(i=0; in; i++)
{
if (i mid)
a[i] = a[i] + b[i];
else
a[i] = a[i] + c[i];
}
}
chf...@pathscale:~/gcc$ gcc -O3 -ftree-vectorizer-verbose=7 -c foo.c
foo.c:6:
I just tried to compile the package normaliz-2.2
with the C++ compiler version 4.5 snapshot 20100311 and it said
vector_operations.cpp: In function 'std::vectorlong int v_make_prime(const
std::vectorlong int, Integer)':
vector_operations.cpp:300:17: error: statement marked for throw in middle of
1 - 100 of 172 matches
Mail list logo
