http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
--- Comment #4 from Joost VandeVondele
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 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 (the 32-bit case is also better
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
Richard Guenther changed:
What|Removed |Added
Target||arm-linux-gnueabi
Status|U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #10 from Anders F Björklund
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 -j .go_export $1 $2
The Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265
Dominique d'Humieres changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment
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 ()
{
int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #11 from Anders F Björklund
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 -d ' ' | xxd -r -p - $2
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 woul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50272
--- Comment #3 from Richard Guenther 2011-09-02
09:28:09 UTC ---
Bah, stupid benchmarks ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818
Richard Guenther changed:
What|Removed |Added
CC||almeidaraf at gmail dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50270
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
Richard Guenther changed:
What|Removed |Added
CC||dominiq at lps dot ens.fr
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50264
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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 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 check that bitset<32>(x).count()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Paolo Carlini changed:
What|Removed |Added
Attachment #25174|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #12 from Richard Guenther 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:
>
>D.2129[24];
>
> and accesse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #13 from Richard Guenther 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 = build_nonstandard_integer_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 changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
Richard Guenther 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
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=gcc&view=rev&rev=178463
Log:
2011-09-02 Paolo Carlini
Marc
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:
...
:
D.2099_18 = MEM[(int *)&D.2129][5]{lb: 0 sz: 4};
__builti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Paolo Carlini changed:
What|Removed |Added
Target Milestone|--- |4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #10 from Paolo Carlini 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 when
I implemented it, I remembe
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
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #11 from Marc Glisse 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 an expert in this area, and when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274
--- Comment #1 from Romain Geissler
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 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:
> ...
> :
> D.2099_18 = MEM[(int *)&D.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #12 from Anders F Björklund
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 Stream_from_file was horribly buggy.
(appar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
--- Comment #13 from Anders F Björklund
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. outside "libgo" directory.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50274
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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 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 changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #12 from Paolo Carlini 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 doing something like this: what
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #13 from Marc Glisse 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 like this: what do you think? C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #14 from Paolo Carlini 2011-09-02
12:33:40 UTC ---
(In reply to comment #13)
> Doesn't _Base_bitset<1> also need a special case for
> _Nb==_GLIBCXX_BITSET_BITS_PER_WORD ?
You are right, got confused by the signedness.
> I think we c
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 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 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 performance.
But to be 100% Fort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276
--- Comment #1 from Joel Yliluoma 2011-09-02 13:04:31
UTC ---
Even this produces the warning. Changing any of the "0"s into "1" did not
affect the warning.
static inline unsigned testfun(void*)
{
return 0;
}
template
static inline unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255
--- Comment #6 from Stephan Bergmann 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 least):
When compiling vbasheetobjects.cxx, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Paolo Carlini changed:
What|Removed |Added
Attachment #25178|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #16 from Marc Glisse 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
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=gcc&view=rev&rev=178474
Log:
gcc/
PR target/49987
* co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
--- Comment #3 from 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 the front
end's job is to produc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #17 from 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=gcc&view=rev&rev=178475
Log:
2011-09-02 Paolo Carlini
Mar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
--- Comment #4 from Richard Guenther 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=gcc&view=rev&rev=178480
Log:
2011-09-02 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460
--- Comment #5 from Richard Guenther 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=gcc&view=rev&rev=178480
Log:
2011-09-02 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49886
--- Comment #4 from Martin Jambor 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=gcc&view=rev&rev=178482
Log:
2011-09-02 Martin Jambor
PR middle-end/49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
Dominique d'Humieres changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972
--- Comment #8 from Bernd Schmidt 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 changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #9 from Jakub Jelinek 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 expressions if it is !amd->s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
Peter Bergner changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #10 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50267
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277
--- Comment #1 from Andrew Pinski 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
2011-09-02 16:51:42 UTC ---
On Fri, Sep 2, 2011 at 12:45 PM, pinskia at gcc dot gnu.org
wrote:
> --- Comment #1 from Andrew Pinski 2011-09-02
> 16:45:15 UTC ---
> strndup is part of the libc that comes f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277
--- Comment #3 from Ivan Tubert-Brohman
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 libiberty/strndup.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50277
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278
--- Comment #1 from H.J. Lu 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 )
LOGICALCNAME, SNAME
CHARACTER*1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #11 from William J. Schmidt
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 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 happen to
> correspo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43598
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
--- Comment #6 from Michael Matz 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=gcc&view=rev&rev=178489
Log:
PR middle-end/50260
* ipa-split.c (split_func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087
eric-bugs at omnifarious dot org changed:
What|Removed |Added
CC||eric-bugs at omnifarious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37110
nicolas.boulenguez at free dot fr changed:
What|Removed |Added
CC||nicolas.boulenguez at f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
--- Comment #3 from Behzad Salimi 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 required even when the "name" 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 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
constexpr expansion in n
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 changed:
What|Removed |Added
Component|c |inline-asm
Severity|major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50280
--- Comment #1 from Andrew Pinski 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 changed:
What|Removed |Added
Component|c |target
Severity|major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #2 from Andrew Pinski 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 what you
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
(
"pu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #6 from Andrew Pinski 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 gave as there is an ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37110
--- Comment #5 from nicolas.boulenguez at free dot fr 2011-09-03 03:23:36 UTC
---
-- There were two distinct bugs.
package P is
type T1 is tagged null record;
type T2 is tagged null record;
function Func (Func_Formal : in T1'Class;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #7 from NickParker at Eaton dot com 2011-09-03 04:45:08 UTC ---
Please ignore the r10/r20 guff I was experimenting. I later realised the
muls3s3u3 code gives the right answer, the problem occurs later on somehow
Nick.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281
--- Comment #8 from NickParker at Eaton dot com 2011-09-03 04:46:45 UTC ---
Please ignore the r10/r20 guff I was experimenting. I later realised the
muls3s3u3 code gives the right answer, the problem occurs later on somehow the
registers where the
95 matches
Mail list logo
