http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #12 from Jakub Jelinek 2011-03-26
09:23:03 UTC ---
Author: jakub
Date: Sat Mar 26 09:23:01 2011
New Revision: 171548
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171548
Log:
Backport from mainline
2011-03-20 Jakub J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #11 from Jakub Jelinek 2011-03-21
17:57:41 UTC ---
Author: jakub
Date: Mon Mar 21 17:57:34 2011
New Revision: 171252
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171252
Log:
PR c/42544
PR c/48197
* c-common.c (sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #10 from Jakub Jelinek 2011-03-19
15:17:06 UTC ---
BTW, this failed already in gcc 2.7.2.3, so doesn't seem to be a regression.
I think we want to fix it in 4.6 nevertheless, but only after 4.6.0 is
released.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #9 from Jakub Jelinek 2011-03-19
15:06:14 UTC ---
Created attachment 23723
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23723
gcc47-pr48197.patch
Maybe, but it might not be very easy, as it is related to diagnostics too (both
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #8 from Richard Guenther 2011-03-19
12:34:55 UTC ---
(In reply to comment #7)
> I think the bug is in shorten_compare.
> We are called for GT_EXPR with op0 0LL and op1 (unsigned) (short) ((short) 0 ^
> (short) y)
> with long long resu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2011-03-19 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #6 from John Regehr 2011-03-18 20:23:32
UTC ---
Bleh... nevermind the longer test, it carries along my misunderstanding of the
sign extension. Anyway, thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #5 from John Regehr 2011-03-18 20:14:51
UTC ---
Here's a test case:
int printf(const char *format, ...);
int main (void)
{
int y = 0x8000;
int x1 = (long)0 > ((unsigned int)0 ^ (signed short)y);
int x2 = (long)0 > ((unsigned i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #4 from John Regehr 2011-03-18 20:12:31
UTC ---
Thanks Jakub, I was just about to send the same example!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #3 from Jakub Jelinek 2011-03-18
20:09:18 UTC ---
That's true, the step from the 3rd to 4th line is wrong.
But that doesn't mean that on LP64 targets it should print 1.
On:
extern void abort (void);
static int y = 0x8000;
int
main
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #2 from John Regehr 2011-03-18 20:04:04
UTC ---
(In reply to comment #1)
>x = (long)0 > ((unsigned int)0 ^ (signed short)0x8000);
>x = (long)0 > ((unsigned)0 ^ (unsigned)0x8000);
> I think you missed something here (unsigned)(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197
--- Comment #1 from Andrew Pinski 2011-03-18
19:56:42 UTC ---
x = (long)0 > ((unsigned int)0 ^ (signed short)0x8000);
x = (long)0 > ((unsigned)0 ^ (unsigned)0x8000);
I think you missed something here (unsigned)(signed short) still sign exte
15 matches
Mail list logo
