Hi all,
Right now I attempts to port the GCC backend to a MCU with very
limited hard registers: only one 8 bit ACC reg, one 16 bit base reg
for addressing, one stats reg.
I searched the GCC backend porting, and seems 68HC1X has the similar
scene, but it use many ram simulated register. I wonder
Almost certainly you will run into severe problems in the reload phase.
You might also profitably study the ip2k port. This is a ALU machine, but it
does have multiple
address registers.
-Original Message-
From: redriver jiang jiang.redri...@gmail.com
Sent: Mar 17, 2010 8:55 AM
To:
We only had one real 8-bit accumulator on that port (the W register) which we
did not expose the RA, instead exposing 32 virtual 8-bit registers from which
we could construct 8, 16, 32 and 64-bit pairs. The key to really good code
generation was to aggresively split the larger
On Tue, 16 Mar 2010 06:50:30 -0800, H.J. Lu hjl.to...@gmail.com wrote:
2010/3/8 Pawe=C5=82 Sikora pl...@agmk.net:
hi,
during development a cross platform appliacation on x86 workstation
i've enabled an alignemnt checking [1] to catch possible erroneous
code before it appears on
Hi,
I am quite confused with libgcc-arch.ver details. I can't find any
documentation on this file except by looking at the files that already
exist.
So, let me see if I got this write. The file
config/arch/libgcc-arch.ver tells gcc to build libgcc so that it
export the symbols listed there
Hi folks.
I am debugging a bunch of Fortran -fdebug-compare failures on the
testsuite, all of which stem from symbols ending up on different alias
set slots. Notice the 2 versus 3 discrepancy below:
(insn:TI# 0 0 a.f90:3 (set (mem/c/i:SI (symbol_ref:DI (i.0.1535)
[flags 0x2] var_decl # i.0) [2
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set. It matters not that we reset DECL_RTL
immediately after, we have already
My problems with GCC 4.4- were solved as suggested by adding in more
multiply patterns specifically smulsi3_highpart, which enabled
reciprocal multiplication to work. GCC 3.4.4 seems to be happy without
this, don't know why.
I have now built a mingw32 build of my private port, built on x86_64
On Wed, Mar 17, 2010 at 5:32 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set. It
On Wed, Mar 17, 2010 at 5:51 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Mar 17, 2010 at 5:32 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
I guess best would be to make sure no new alias set is created in these
places. Perhaps
int save_strict_aliasing = flag_strict_aliasing;
flag_strict_aliasing = 0;
rtl = DECL_RTL (decl);
flag_strict_aliasing = save_strict_aliasing;
in both places?
Remember when I said I had come up with
? ? rtl = DECL_RTL (decl);
? ? /* Reset DECL_RTL back, as various parts of the compiler expects
? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/
? ? SET_DECL_RTL (decl, NULL);
... why do this in the first place? ?Is this an issue for all decls or just
for
On Wed, Mar 17, 2010 at 6:28 PM, Aldy Hernandez al...@redhat.com wrote:
? ? rtl = DECL_RTL (decl);
? ? /* Reset DECL_RTL back, as various parts of the compiler expects
? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/
? ? SET_DECL_RTL (decl, NULL);
... why do this in
On Wed, Mar 17, 2010 at 6:40 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Mar 17, 2010 at 6:28 PM, Aldy Hernandez al...@redhat.com wrote:
? ? rtl = DECL_RTL (decl);
? ? /* Reset DECL_RTL back, as various parts of the compiler expects
? ? ? ?DECL_RTL set meaning it is
redriver jiang jiang.redri...@gmail.com writes:
Right now I attempts to port the GCC backend to a MCU with very
limited hard registers: only one 8 bit ACC reg, one 16 bit base reg
for addressing, one stats reg.
I searched the GCC backend porting, and seems 68HC1X has the similar
scene, but
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 modified toolchain. We don't run loop opt after
register allocation. See the
On Tue, 2010-03-16 at 15:12 +0800, Amker.Cheng wrote:
In my understanding, the macro GENERATE_MADD_MSUB is true when the processor
has
madd insn, rather than madd2. And the macro ISA_HAS_DMUL3 is false if it
has
no mul insn.
for this kind processor, gcc will
step 1 : generate insn using
On Wed, Mar 17, 2010 at 06:40:30PM +0100, Richard Guenther wrote:
var_decl 0x7794d140 __BLNK__
type record_type 0x779493f0 SI
size integer_cst 0x77854988 constant 32
unit size integer_cst 0x77854690 constant 4
align 32 symtab 0 alias set -1
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 the point debug info is generated only
the
Are you suggesting we remove the entire code path here:
?/* Try harder to get a rtl. ?If this symbol ends up not being emitted
? ? in the current CU, resolve_addr will remove the expression referencing
? ? it. ?*/
??
Yes.
That will very much pessimize debug info.
DWARF Version 4 Released
March 17, 2010
The DWARF Debugging Information Format Committee is pleased to announce the
availability of the public review draft of Version 4 of the DWARF Debugging
Information Format standard. The DWARF debugging format is used to communicate
information between a
On Wed, Mar 17, 2010 at 06:08:06PM -0400, Aldy Hernandez wrote:
So... Richi, et al. Instead, should I remove alias set numbers
on the -fcompare-debug case, or inhibit new alias sets like thus:
unsigned int save_aliasing = flag_strict_aliasing;
flag_strict_aliasing = 0;
do
Hi Kenneth,
The documentation of auto-inc-dec still refers to flow and when I
raised this on IRC folks suggested that you might have some
documentation fixes if any, in this area.
http://gcc.gnu.org/onlinedocs/gccint/Incdec.html#Incdec
The lines in the doco are as below :
These embedded side
i will fix it.
kenny
On 03/17/2010 07:28 PM, Ramana Radhakrishnan wrote:
Hi Kenneth,
The documentation of auto-inc-dec still refers to flow and when I
raised this on IRC folks suggested that you might have some
documentation fixes if any, in this area.
Paulo J. Matos pocma...@gmail.com writes:
I am quite confused with libgcc-arch.ver details. I can't find any
documentation on this file except by looking at the files that already
exist.
So, let me see if I got this write. The file
config/arch/libgcc-arch.ver tells gcc to build libgcc so
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 function call). I would expect many switch
--- Comment #10 from bonzini at gnu dot org 2010-03-17 06:41 ---
REG_EQUAL notes are not there to guarantee correctness. Relying on them to
avoid misoptimization is always wrong and just hides the bug.
It is a regression from 4.2.
--
bonzini at gnu dot org changed:
--- Comment #3 from fjoe at samodelkin dot net 2010-03-17 07:09 ---
The source of library bar is:
--- cut here ---
#include foo.h
#ifdef _MSC_VER
#define BAR_API __declspec(dllexport)
#else
#define BAR_API __attribute__((visibility(default)))
#endif
void BAR_API
bar()
{
Foo
--- Comment #4 from pluto at agmk dot net 2010-03-17 07:57 ---
this PR sounds like a PR38610.
--
pluto at agmk dot net changed:
What|Removed |Added
CC|
--- Comment #11 from steven at gcc dot gnu dot org 2010-03-17 08:23 ---
So why not just something like the following:
Note that uses in REG_EQUAL notes are taken into account in
the computation of invariants. Hence it is safe to retain the
note even if the
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-17 08:30 ---
If it is ok to call check_maybe_invariant in this spot, then I think that's the
right fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
--- Comment #13 from steven at gcc dot gnu dot org 2010-03-17 08:33 ---
Mine.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2010-03-17 08:59
---
I just posted the same fix. :-) Yes, it is OK for all branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-17 09:20 ---
Actually, this seems to be a C FE bug, corruption of TREE_CHAIN chains.
The reason for dwarf2out hanging is that in foo we have a block:
BLOCK #0 [written]
SUPERCONTEXT: foo
VARS: vector_size foo i h
Note that
--- Comment #27 from bernds at gcc dot gnu dot org 2010-03-17 09:25 ---
Subject: Bug 42216
Author: bernds
Date: Wed Mar 17 09:25:35 2010
New Revision: 157511
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157511
Log:
PR rtl-optimization/42216
* regrename.c
--- Comment #12 from burnus at gcc dot gnu dot org 2010-03-17 09:30 ---
Close as fixed as only PR 42954 remains to be done.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-17 09:31 ---
Cross reference: The missing define of _WIN32 causes failures on
MinGW/MinGW64 for gfortran.dg/dev_null.F90 and gfortran.dg/write_to_null.F90.
(cf. PR 42950 which is otherwise fixed.)
--
I found that when I emerged libcaca 0.99 beta 16, I got 2 ICEs in demo.c
and demo0.c. After some code cutting I got down to [attached demo.i]. Note that
draw_circle isn't defined, it was a real function in libcaca's
demo.c. Also, the there's an -O flag, removing it causes an error on
--- Comment #1 from scientica at gmail dot com 2010-03-17 09:40 ---
Created an attachment (id=20122)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20122action=view)
the crash case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43398
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-17 09:53 ---
Subject: Bug 43331
Author: burnus
Date: Wed Mar 17 09:53:40 2010
New Revision: 157512
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157512
Log:
2010-03-17 Tobias Burnus bur...@net-b.de
PR
--- Comment #19 from rguenther at suse dot de 2010-03-17 10:01 ---
Subject: Re: [4.5 Regression] Empty loop not
removed
On Wed, 17 Mar 2010, changpeng dot fang at amd dot com wrote:
--- Comment #17 from changpeng dot fang at amd dot com 2010-03-17 00:18
---
(In
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-17 10:03 ---
FIXED on the trunk (4.5).
Richard: Thanks for the clear bug report! And for making the middle-end smarter
with regards to bonds.
Actually, will this middle-end change cause problems for inlining such
old-style
--- Comment #7 from rguenther at suse dot de 2010-03-17 10:07 ---
Subject: Re: Cray pointers generate bogus IL for the
middle-end
On Wed, 17 Mar 2010, burnus at gcc dot gnu dot org wrote:
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-17 10:03
---
FIXED on
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-17 10:47 ---
From
[3] ISO/IEC 14882-1998 [conv.prom] An rvalue for an integral bit-field can be
converted to an rvalue of type int if int can represent all the values of the
bit-field; otherwise, it can be converted to unsigned
--- Comment #20 from doko at ubuntu dot com 2010-03-17 10:51 ---
no change in the libjava testsuite when built with these binutils
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
--- Comment #5 from redi at gcc dot gnu dot org 2010-03-17 10:54 ---
I think the behaviour is intentional, for the same reasons described at
http://gcc.gnu.org/wiki/Visibility#Problems_with_C.2B-.2B-_exceptions_.28please_read.21.29
Instantiated templates (such as Foo::fooint) have vague
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-17 10:58 ---
Reduced testcase at -g -O2 on x86_64 grows during var-tracking get_max_uid ()
from ~ 22000 to over a 100. Adding ten X4's instead of 1 of course eats
even more memory.
extern void *f1 (void *, void *, void *);
--- Comment #4 from bernds at codesourcery dot com 2010-03-17 11:05 ---
It's not immediately obvious to me why the ARM mulsi3 patterns are written the
way they are - what are the earlyclobber tricks supposed to be good for?
Richard E., any clues?
--
bernds at codesourcery dot com
--- Comment #5 from bernds at codesourcery dot com 2010-03-17 11:44 ---
Created an attachment (id=20123)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20123action=view)
A patch to fix it.
Okay, so the pattern is written strangely because it's a two-operand mul where
the input and
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-17 11:59 ---
Perhaps add a comment why the peephole is needed? That information tend to get
lost rather quickly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-03-17 12:02 ---
Subject: Bug 43347
Author: jamborm
Date: Wed Mar 17 12:02:35 2010
New Revision: 157515
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157515
Log:
2010-03-17 Martin Jambor mjam...@suse.cz
PR
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-03-17 12:04 ---
Fixed with http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00694.html
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
current trunk is failing bootstrap in stage 1 on Cortex-A8 (armv7l target)
First caught it svn 157489. Started bisection yesterday between 157445
157489. First bad commit is: 157476.
System is running Debian Testing(Squeeze)
Error:
/opt/trunk/objdir/./gcc/xgcc -B/opt/trunk/objdir/./gcc/
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-17 12:56 ---
Please provide preprocessed source.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2010-03-17 12:57 ---
New test fails with:
Executing on host: /space/uros/gcc-build/gcc/xgcc -B/space/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43379.c -O2 -ftracer -S -o
pr43379.s(timeout = 300)
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-17 13:44 ---
I fixed htat.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
While crosscompiling gcc 4.5.0 svn rev. 157515, it barfs while compiling
itself:
/usr/src/CVS/toolchains/gcc-4.5.0/build/./gcc/xgcc
-B/usr/src/CVS/toolchains/gcc-4.5.0/build/./gcc/
-B/usr/armv6j-blankpage-linux-gnueabi/bin/
-B/usr/armv6j-blankpage-linux-gnueabi/lib/ -isystem
On the assigned file you can reproduce the bug.
If you compile this file with -O2 the error occures, only way is use -O0 or use
volatile statement for the double arrays.
I think this should be checkt during optimization.
Greets,
Matthias
--
Summary: Register not cleand correctly
--- Comment #1 from matthias at goldhoorn dot eu 2010-03-17 13:48 ---
Created an attachment (id=20124)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20124action=view)
source file where the bugg occures
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
--
matthias at goldhoorn dot eu changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-17 13:51 ---
*** Bug 43400 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-17 13:51 ---
*** This bug has been marked as a duplicate of 43399 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from matthias at goldhoorn dot eu 2010-03-17 13:54 ---
Created an attachment (id=20125)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20125action=view)
Object dump without optization
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
--- Comment #3 from matthias at goldhoorn dot eu 2010-03-17 13:55 ---
Created an attachment (id=20126)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20126action=view)
Object Dumpo with optimization (broken result)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
--- Comment #4 from matthias at goldhoorn dot eu 2010-03-17 13:57 ---
Forgotten output with optimization:
(10.00,20.00)
(0.00,0.00)
(0.00,0.00)
(0.00,0.00)
sould be:
(10.00,20.00)
(10.00,20.00)
(10.00,20.00)
(10.00,20.00)
This actually happens in libicu, preventing genbrk (and hence openoffice and
texlive) to work.
# gcc -O1 icubug.c ./a.out
Aborted
With -O0 it works. The wrong transformation is done by dom1, it transforms
the loop into a linear sequence without backedges.
bb 2:
goto bb 8;
bb 3:
#
--- Comment #1 from matz at gcc dot gnu dot org 2010-03-17 14:02 ---
Created an attachment (id=20127)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20127action=view)
testcase
Testcase reduced from ucnv_bld.c of libicu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #3 from robertcnelson at gmail dot com 2010-03-17 14:04 ---
Rebuilding 157476, will take a couple hours to hit that error..
System: gcc -v
voo...@beagle-256mb-1:~$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|dom1 miscompiles binary |[4.5 Regression] dom1
|search
/home2/dave/gcc-4.5/objdir/./gcc/xgcc -B/home2/dave/gcc-4.5/objdir/./gcc/
-B/hom
e2/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home2/dave/opt/gnu/gcc/gcc-4.5.
0/hppa-linux/lib/ -isystem /home2/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include
-isystem
Thread model: posix
gcc version 4.5.0 20100317 (experimental) [trunk revision 157506] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-17 14:41 ---
Can you attach preprocessed source?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-03-17 14:42 ---
Mine. Looking into it now.
We might even want to simply relax the checking if it triggers on lately build
stuff like tinfos. Let me see if I can avoid tinfos producing mallformed
decls.
--
hubicka at gcc dot gnu
--- Comment #3 from dodji at gcc dot gnu dot org 2010-03-17 14:55 ---
A patch was proposed at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00662.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-17 14:57 ---
This is points-to information being computed wrongly. A lot was fixed for
GCC 4.4.x in this area.
The constraints are already wrong:
arr = a
arr.32 = b
arr.64 = c
arr.96 = d
D.2332_12 = arr
With 4.4 and 4.5 we
Tested with GCC 4.4.1 and 4.4.3 (custom built) on Arch Linux
host arch is x86_64 and target is arm-elf
This is the full source code needed to reproduce the bug:
void __data_abort(void) __attribute__ ((naked));
void __data_abort(void)
{
long foo;
long* bar = foo;
}
test.c: In function
--- Comment #1 from marti at juffo dot org 2010-03-17 15:03 ---
Created an attachment (id=20128)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20128action=view)
test.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43404
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-17
15:03 ---
Subject: Re: [4.5 Regression] ICE in stage1 compiling
__bswapdi2
Can you attach preprocessed source?
Attached.
Dave
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-17
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-17 15:05 ---
Created an attachment (id=20130)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20130action=view)
gcc45-pr43058.patch
So far untested fix. This just optimizes handling of optimized out variables
which are known
--- Comment #2 from spop at gcc dot gnu dot org 2010-03-17 15:13 ---
This looks like a duplicate of PR42860.
This works on gcc4.5.
*** This bug has been marked as a duplicate of 42860 ***
--
spop at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from spop at gcc dot gnu dot org 2010-03-17 15:13 ---
*** Bug 43398 has been marked as a duplicate of this bug. ***
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from spop at gcc dot gnu dot org 2010-03-17 15:14 ---
See PR43398 for a nicely reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43381
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43384
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-17 15:19 ---
Waiting for testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-17 15:21 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-17 15:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
sinl (and probably others) are not computed correctly. At least for large
inputs.
Please consider the following simple testcase:
$ cat sintest.c
#include stdio.h
#include math.h
int
main (void) {
double arg = 1e22;
long double larg = 1e22L;
printf(double precision: sin(1e22) =
--- Comment #1 from eli dot osherovich at gmail dot com 2010-03-17 15:29
---
Created an attachment (id=20131)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20131action=view)
testcase as a standalone file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43405
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-17 15:31 ---
It seems the jump threading somehow confuses cfgcleanup. Right after the
jumps are threaded (in tree_ssa_dominator_optimize after the call to
thread_through_all_blocks) the function looks like so:
bb 2:
goto bb 9;
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-17 15:36 ---
Um, we cleanup the CFG before updating SSA form, hence no wonder that
the missing PHI nodes confuse it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #4 from robertcnelson at gmail dot com 2010-03-17 15:42 ---
Here here is the preprocessed source.
http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399/save-temps.log
http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399/libgcc2.i
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-17 15:49 ---
Hmm, create_edge_and_update_destination_phis is supposed to add new PHI
arguments for the ultimate threading destination. But it only does so if
there are already PHI nodes in that BB. We need to create new ones,
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-17 15:51 ---
It is caused by revision 157093:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00676.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Sample code:
#include stdio.h
int main (void)
{
long long a = 0xLL; // 48 bits set
int popcount;
#if 1
popcount = __builtin_popcountll (a);
#else
popcount = __popcountdi2 (a);
#endif
printf (%llx popcount = %d\n, a, popcount);
return 0;
}
If -mpopcnt is
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-17 16:05 ---
Hmm, I wonder how that could cause the bug. Probably because we can't rely
on SSA form being uptodate during cfgcleanup, and hence looking up PHI
arguments is wrong, at least for those SSA names that are registered
--- Comment #1 from rbarreira at gmail dot com 2010-03-17 16:35 ---
Note that if you use scanf (%llx, a) and input instead of
having a hardcoded value for a, the bug happens both with -O3 and -O0.
To sum up it seems that when the popcnt instruction is actually issued, it's
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-17 16:36 ---
var-tracking expects that if frame_pointer_rtx (resp. arg_pointer_rtx,
depending on whether FRAME_POINTER_CFA_OFFSET or ARG_POINTER_CFA_OFFSET is
defined)
is said to be eliminated (to stack_pointer_rtx in case of
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-17 16:42 ---
(In reply to comment #7)
Hmm, I wonder how that could cause the bug. Probably because we can't rely
on SSA form being uptodate during cfgcleanup, and hence looking up PHI
arguments is wrong, at least for those
If one specifies any visibility attribute on an enum class emits the type
attributes ignored after type is already defined warning.
Easy to reproduce! Just add the following lines anywhere and compile them
(without -Wno-attributes):
enum class __attribute__((visibility(default))) Number
{
1 - 100 of 163 matches
Mail list logo
