--- Comment #12 from bonzini at gnu dot org 2008-05-31 07:25 ---
*** Bug 36398 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from bonzini at gnu dot org 2008-05-31 07:25 ---
I think this was expected, the test should probably be XFAILed.
*** This bug has been marked as a duplicate of 19020 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
---
This testcase:
#include
__m128i r(__m128 d1, __m128 d2, __m128 d3, __m128i r, int t, __m128i s) {return
r+s;}
compiles to:
_r:
subl$12, %esp
movdqa %xmm3, %xmm0
paddq 32(%esp), %xmm0
addl$12, %esp
ret
with apple gcc 4.0 and 4.2.
It compiles t
--- Comment #9 from janus at gcc dot gnu dot org 2008-05-31 09:17 ---
Ok, apparently rev. 136130 *did* in fact also fix the test case in comment #1
(although I somehow assumed otherwise), and therefore this whole PR is fixed.
Should I add another test case with an assumed shape array (o
--- Comment #3 from bonzini at gnu dot org 2008-05-31 09:18 ---
Well, regression is a big word because -ftrapv is broken in general. I guess
the RM will lower the priority.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
In
struct barstruct { char const* some_string; };
void changethepointer(struct barstruct***);
void baz()
{
struct barstruct bar1;
struct barstruct* barptr = &bar1;
struct barstruct** barptr2 = &barptr;
changethepointer(&barptr2);
barptr->some_string = "Everything OK";
}
the store to b
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-31 10:23 ---
Wrong points-to result is split out to PR36400.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36387
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-31 10:33 ---
The patch from
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg02060.html
seems to work.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-31 10:58 ---
As apple implements the darwin ABI in the FSF gcc it's apples turn to fix it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from janus at gcc dot gnu dot org 2008-05-31 11:03 ---
I tried to reduce this as far as I could, and ended up with:
subroutine sub(x)
abstract interface
character function abs_fun()
end function
end interface
procedure(abs_fun):: x
end subroutine
So, contra
--- Comment #2 from janus at gcc dot gnu dot org 2008-05-31 11:18 ---
valgrind gives the following backtrace:
==19018== Invalid read of size 4
==19018==at 0x80E71EA: gfc_conv_const_charlen (trans-const.c:179)
==19018==by 0x811B61A: gfc_get_function_type (trans-types.c:2077)
==19
--- Comment #3 from janus at gcc dot gnu dot org 2008-05-31 11:45 ---
The fix:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 136234)
+++ gcc/fortran/resolve.c (working copy)
@@ -7751,6 +77
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-31 13:01 ---
Fixed for 4.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-31 13:01 ---
Subject: Bug 36262
Author: rguenth
Date: Sat May 31 13:01:10 2008
New Revision: 136237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136237
Log:
2008-05-31 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-05-31 13:01
---
Subject: Bug 34244
Author: rguenth
Date: Sat May 31 13:01:10 2008
New Revision: 136237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136237
Log:
2008-05-31 Richard Guenther <[EMAIL PROTECTED]>
At -O3 -funroll-loops -fpeel-loops -ffast-math
revision 136224, last known good 136189.
--
Summary: [4.4 Regression] 164.gzip miscompares
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-31 13:56 ---
Two likely changes:
+2008-05-30 Richard Guenther <[EMAIL PROTECTED]>
+
+ * builtins.c (build_string_literal): Avoid generating
+ a non-gimple_val result.
+2008-05-30 Steven Bosscher <[EMAIL PROTECTE
--- Comment #5 from mt-ml at gmx dot de 2008-05-31 13:58 ---
Created an attachment (id=15707)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15707&action=view)
preprocessed sources of urb.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
--- Comment #6 from mt-ml at gmx dot de 2008-05-31 13:59 ---
I was able to find the function in which the error occurs. It's usb_submit_urb
in drivers/usb/core/urb.c I think.
The command:
$ gcc -c -save-temps drivers/usb/core/urb.c -I include
executed in the linux-kernel main directory g
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-31 15:45 ---
Looking at http://www.readcode.org/code/linux-2.6.20/include/linux/log2.h it
seems that either the argument to ilog _is_ zero or the compiler thinks so.
--
rguenth at gcc dot gnu dot org changed:
What
GCC seems to treat the 32-bit integer constant -0x8000 (INT_MIN) as an
unsigned value, when it should be signed. (I don't think this is a duplicate
of bug 25329, since I'm not trying to negate the constant.) For example:
int a = 1;
int foo(void)
{
return -0x8000 < a;
}
improperly re
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-05-31 19:50
---
> GCC seems to treat the 32-bit integer constant -0x8000 (INT_MIN) as an
> unsigned value, when it should be signed.
Incorrect. -0x8000 is not an integer constant, it's the negation of the
integer consta
--- Comment #2 from paolo at gcc dot gnu dot org 2008-05-31 23:01 ---
Subject: Bug 36338
Author: paolo
Date: Sat May 31 23:01:09 2008
New Revision: 136242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136242
Log:
2008-05-31 Paolo Carlini <[EMAIL PROTECTED]>
Chris
--- Comment #3 from paolo dot carlini at oracle dot com 2008-05-31 23:02
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Several fortran tests using eoshift fail for SH. The typical one is
gfortran.dg/char_length_8.f90 -O0 execution test
and its reduced testcase is
CHARACTER(LEN=3), DIMENSION(10) :: Z
call test_eoshift
contains
subroutine test_eoshift
CHARACTER(LEN=1), DIMENSION(10) :: chk
chk(1:
--- Comment #1 from hutchinsonandy at aim dot com 2008-06-01 01:02 ---
I have reduced number of failures slightly by setting higher optimisation and
skipping complex int using
set COMPAT_SKIPS [list {VA} {COMPLEX_INT}]
set COMPAT_OPTIONS [list [list {-Os -mcall-prologues} {-Os -mcall-
--- Comment #13 from hutchinsonandy at aim dot com 2008-06-01 02:40 ---
expr.c appears all messed up on emit_single_push_insn.
This bad code gets executed when there is no push instruction available.
As well as getting address of the mem created completely wrong, it does not
account fo
--- Comment #2 from gcczilla at achurch dot org 2008-06-01 04:17 ---
Fair enough, but GCC's documentation explicitly says (gcc.info section 4.5):
* `Whether signed integer types are represented using sign and
magnitude, two's complement, or one's complement, and whether the
28 matches
Mail list logo
