Hi,
For the following small case,
int f(int i, int j)
{
if (i==1 j==2)
return i;
else
return j;
}
with -O2 option, GCC has vrp2 dump like below,
==
Value ranges after VRP:
i_1: VARYING
i_2(D): VARYING
D.1249_3: [0, +INF]
On Thu, Sep 1, 2011 at 10:58 PM, Jiangning Liu jiangning@arm.com wrote:
D.1249_3: [0, 1]
D.1250_5: [0, 1]
D.1251_6: [0, 1]
Those are equivalent to [0, MAX] as _Bool only has two different
values, 0 and 1 (MAX). Can you explain more about the optimization
which you are working on that
On Fri, Sep 2, 2011 at 7:58 AM, Jiangning Liu jiangning@arm.com wrote:
Hi,
For the following small case,
int f(int i, int j)
{
if (i==1 j==2)
return i;
else
return j;
}
with -O2 option, GCC has vrp2 dump like below,
Andrew,
I realize I needn't back-end solution for my case at all, and in middle end I
can directly use the _Bool type info! Appreciate your reply!
Thanks,
-Jiangning
-Original Message-
From: Andrew Pinski [mailto:pins...@gmail.com]
Sent: Friday, September 02, 2011 2:27 PM
To:
Snapshot gcc-4.6-20110902 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110902/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50272
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #9 from Anders F Björklund afb at users dot sourceforge.net
2011-09-02 06:40:28 UTC ---
(In reply to comment #8)
hello world tests OK on Snow Leopard, with patch
This patch fails on darwin11 when applied to gcc-4_6-branch...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50244
--- Comment #5 from lcid-fire at gmx dot net 2011-09-02 06:41:29 UTC ---
It seems to be a mixup of gcc 4.4.3 and 4.5.3 include paths. Obviously the
headers are quite different - I'll have to sort it out.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2011-09-02 07:27:30 UTC ---
Patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00052.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #6 from Marc Glisse marc.glisse at normalesup dot org 2011-09-02
08:03:22 UTC ---
(In reply to comment #5)
This one is much better, and actually should lead to slightly better code than
C++98, because we don't do anything if _Nw 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #10 from Anders F Björklund afb at users dot sourceforge.net
2011-09-02 08:45:22 UTC ---
Here's my attempt at a native version.
(of that gox-extract shell script)
Instead of the default variant:
OBJCOPY=${OBJCOPY:-objcopy}
$OBJCOPY
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||mjambor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #9 from vries at gcc dot gnu.org 2011-09-02 09:03:54 UTC ---
The following testcase reproduces the same failure without alloca, vla, or the
178353 patch.
stack-stave-restore.c:
...
extern void bar (int*);
char *p;
int
main ()
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #11 from Anders F Björklund afb at users dot sourceforge.net
2011-09-02 09:06:25 UTC ---
OTOOL=${OTOOL:-otool}
$OTOOL -s __GNU_GO __go_export $1 |
grep -v ^$1: | grep -v Contents of (__GNU_GO,__go_export) section |
cut -f 2- | tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #10 from vries at gcc dot gnu.org 2011-09-02 09:24:33 UTC ---
The __builtin_stack_restore stays until ira (if we wouldn't by declaring p
global),
The __builtin_stack_restore stays until ira (if we wouldn't declare p
global, it would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50272
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
09:28:09 UTC ---
Bah, stupid benchmarks ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||almeidaraf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50270
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||dominiq at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50264
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #11 from vries at gcc dot gnu.org 2011-09-02 09:37:42 UTC ---
The problems for testcases 20010209-1.c and stack-stave-restore.c can be
reproduced on x86_64 using -mpreferred-stack-boundary=12.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02
09:37:55 UTC ---
Hi,
(In reply to comment #6)
Looks better indeed. I think the compiler should be responsible for optimizing
x~0UL, not the library. I'll have to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Attachment #25174|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
09:40:33 UTC ---
(In reply to comment #3)
Created attachment 25162 [details]
optimized dump
1. The alloca in main is transformed into this declaration:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
09:42:13 UTC ---
(In reply to comment #6)
fold_builtin_alloca_for_var should record stack alignment
change due to
+ /* Declare array. */
+ elem_type =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
Bug #: 50273
Summary: [4.5/4.6/4.7 Regression] -Walign-commons no longer
effective
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.5.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2011-09-02 10:28:40 UTC ---
Author: paolo
Date: Fri Sep 2 10:28:36 2011
New Revision: 178463
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178463
Log:
2011-09-02 Paolo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #14 from vries at gcc dot gnu.org 2011-09-02 10:28:52 UTC ---
but for some reason it doesn't trigger?
The bb containing the __builtin_stack_restore has 2 successors:
...
bb 6:
D.2099_18 = MEM[(int *)D.2129][5]{lb: 0 sz: 4};
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02
10:41:52 UTC ---
(by the way, if you can see a neat enough way to improve _M_are_all_aux, you
are welcome to propose it! I'm definitely not an expert in this area, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274
Bug #: 50274
Summary: Conditionnal rethrow
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #11 from Marc Glisse marc.glisse at normalesup dot org 2011-09-02
10:59:46 UTC ---
(In reply to comment #10)
(by the way, if you can see a neat enough way to improve _M_are_all_aux, you
are welcome to propose it! I'm definitely not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274
--- Comment #1 from Romain Geissler romain.geissler at gmail dot com
2011-09-02 11:00:50 UTC ---
Created attachment 25176
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25176
Rethrow made in foo is not caught in main handler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
11:02:22 UTC ---
(In reply to comment #14)
but for some reason it doesn't trigger?
The bb containing the __builtin_stack_restore has 2 successors:
...
bb 6:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #12 from Anders F Björklund afb at users dot sourceforge.net
2011-09-02 11:07:33 UTC ---
It doesn't include the objcopy header,
but I believe that is skipped anyway ?
Or at least it was *supposed* to ignore it,
but the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #13 from Anders F Björklund afb at users dot sourceforge.net
2011-09-02 11:10:51 UTC ---
Created attachment 25177
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25177
import-export.diff
Just the import/export changes, i.e.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
checking whether
/home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/./gcc/xgcc
-B/home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/./gcc/ -nostdinc
-B/home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/lm32-elf/newlib/
-isystem
/home/philpem/gcc/build-20110902-105609/gcc-4.6.0/build/lm32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265
--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-02
11:28:03 UTC ---
I'm sure it is.
At least on x86_64-apple-darwin10 it is fixed by the patch for pr50260 at
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00052.html .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274
Romain Geissler romain.geissler at gmail dot com changed:
What|Removed |Added
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02
12:08:04 UTC ---
Created attachment 25178
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25178
Work in progress patch for the _M_are_all_aux issue
I'm considering
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #13 from Marc Glisse marc.glisse at normalesup dot org 2011-09-02
12:23:33 UTC ---
(In reply to comment #12)
Created attachment 25178 [details]
Work in progress patch for the _M_are_all_aux issue
I'm considering doing something
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02
12:33:40 UTC ---
(In reply to comment #13)
Doesn't _Base_bitset1 also need a special case for
_Nb==_GLIBCXX_BITSET_BITS_PER_WORD ?
You are right, got confused by the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
Bug #: 50276
Summary: Wrong used uninitialized in this function warning
[C++0x]
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-09-02
12:46:10 UTC ---
4.6 version of the patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00140.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-02
12:57:03 UTC ---
(In reply to comment #1)
./f951 -quiet t.f90 -Wpadded
Note that suggesting -fno-align-commons shouldn't be done - using it
can severely reduce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
--- Comment #1 from Joel Yliluoma bisqwit at iki dot fi 2011-09-02 13:04:31
UTC ---
Even this produces the warning. Changing any of the 0s into 1 did not
affect the warning.
static inline unsigned testfun(void*)
{
return 0;
}
templateint i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255
--- Comment #6 from Stephan Bergmann stephan.bergmann.secondary at googlemail
dot com 2011-09-02 13:15:42 UTC ---
While I still don't have a stripped down test case, I at least know now what is
going wrong (on recent gcc-4_6-branch rev 178396, at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Attachment #25178|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #16 from Marc Glisse marc.glisse at normalesup dot org 2011-09-02
13:26:14 UTC ---
(In reply to comment #15)
I'm finishing testing this.
Looks good, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987
--- Comment #12 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
2011-09-02 13:32:14 UTC ---
Author: rsandifo
Date: Fri Sep 2 13:32:10 2011
New Revision: 178474
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178474
Log:
gcc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-02 13:36:20 UTC ---
I don't think there's any particular reason this initializer should need
to be folded in a particular way by the front end; I'd think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #17 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2011-09-02 13:39:26 UTC ---
Author: paolo
Date: Fri Sep 2 13:39:22 2011
New Revision: 178475
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178475
Log:
2011-09-02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
13:53:37 UTC ---
Author: rguenth
Date: Fri Sep 2 13:53:32 2011
New Revision: 178480
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178480
Log:
2011-09-02 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-02
13:53:37 UTC ---
Author: rguenth
Date: Fri Sep 2 13:53:32 2011
New Revision: 178480
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178480
Log:
2011-09-02 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886
--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-09-02
14:30:49 UTC ---
Author: jamborm
Date: Fri Sep 2 14:30:34 2011
New Revision: 178482
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178482
Log:
2011-09-02 Martin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||bernds at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
--- Comment #8 from Bernd Schmidt bernds at gcc dot gnu.org 2011-09-02
14:49:51 UTC ---
I'm guessing it was this:
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02175.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-02
15:48:44 UTC ---
Ok, I've now managed to reproduce the unspecs in a fresh cross build.
Perhaps adjust_mems could try harder and call targetm.delegitimize_address on
all the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
Peter Bergner bergner at gcc dot gnu.org changed:
What|Removed |Added
CC||amodra at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50267
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277
Bug #: 50277
Summary: strndup should use strnlen instead of strlen
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-02
16:45:15 UTC ---
strndup is part of the libc that comes from your OS and not part of GCC. Most
likely you wanted to file this as a glibc bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277
--- Comment #2 from Ivan Tubert-Brohman ivan.tubert at gmail dot com
2011-09-02 16:51:42 UTC ---
On Fri, Sep 2, 2011 at 12:45 PM, pinskia at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #1 from Andrew Pinski pinskia at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277
--- Comment #3 from Ivan Tubert-Brohman ivan.tubert at gmail dot com
2011-09-02 16:55:07 UTC ---
And the code in glibc already uses strnlen.
Sorry about that. Please close the ticket unless you deem necessary to modify
the version in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278
Bug #: 50278
Summary: [4.7 Regression] SPEC CPU 2000 failed to build
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-09-02 17:27:43
UTC ---
[hjl@gnu-35 delta-fortran]$ cat x.f
INTEGER FUNCTION ILAENV( ISPEC, NAME, OPTS, N1, N2, N3,
$ N4 )
LOGICAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #11 from William J. Schmidt wschmidt at gcc dot gnu.org
2011-09-02 17:44:28 UTC ---
Also, when I built a new cross-compiler over on gcc10, the issue moved from
.LC7 to .LC8 -- so the exact .LC number may vary for whatever reason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #15 from H.J. Lu hjl.tools at gmail dot com 2011-09-02 18:09:41
UTC ---
(In reply to comment #14)
.init_array section is an array of pointers. How do you grep it?
You arrange for the pointers to be assigned values whose bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43598
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 2011-09-02 18:31:56
UTC ---
Author: matz
Date: Fri Sep 2 18:31:47 2011
New Revision: 178489
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178489
Log:
PR middle-end/50260
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087
eric-bugs at omnifarious dot org changed:
What|Removed |Added
CC||eric-bugs at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37110
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
--- Comment #3 from Behzad Salimi riddle00 at gmail dot com 2011-09-02
22:34:27 UTC ---
Hello,
Thank you very much for your reply and help.
Your example pointed me to the clue to find the error in my source:
evidently, a /name/ block is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #16 from vries at gcc dot gnu.org 2011-09-02 22:47:42 UTC ---
Started testing patch from comment 9, augmented with comments:
...
Index: explow.c
===
--- explow.c (revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50279
Bug #: 50279
Summary: go bootstrap fails with lto
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087
--- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-09-03
00:48:25 UTC ---
(In reply to comment #5)
I still think it's a missed optimization opportunity.
Yes, it definitely is. I'm just not sure whether it should be fixed by doing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50280
Bug #: 50280
Summary: Incorrect type deduced for T when passed a const
bitfield
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
Bug #: 50281
Summary: result registers are overwritten giving incorrect
result
Classification: Unclassified
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Component|c |inline-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50280
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-03
01:07:40 UTC ---
It works on the trunk as of 4.7.0 20110823 [trunk revision 178018]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
NickParker at Eaton dot com changed:
What|Removed |Added
Component|inline-asm |c
Severity|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-03
01:13:00 UTC ---
I think your inline-asm is broken.
You have:
: =r (answer)
: r (a_u4), r (b_u4)
: r2,r3,r4,r5,r6,r7,r20
But you modify %1 and %2 which causes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #3 from NickParker at Eaton dot com 2011-09-03 01:28:57 UTC ---
The final printed calculation result of MulU3U3S3() is wrong, because two of
the four result registers are incorrect and have been overwritten.
mulu3u3s3 : [ +0016777215
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #4 from NickParker at Eaton dot com 2011-09-03 01:30:26 UTC ---
Hi Andrew,
Can you please explain what you mean by %1 and %2. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #5 from NickParker at Eaton dot com 2011-09-03 01:32:20 UTC ---
Sorry. I pasted a broken version. Before. Code below works.
uint32_t MulU3U3S3(uint32_t a_u4, uint32_t b_u4)
{
//uint32_t answer;
asm volatile
(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-03
01:38:44 UTC ---
Oh the real issue is that the : r (a_u4), r (b_u4)
Those two arguments could be in r0 or r1. Also the generated asm does not
correspond to the source you
1 - 100 of 173 matches
Mail list logo
