--- Comment #4 from jason at gcc dot gnu dot org 2010-08-21 06:27 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from ubizjak at gmail dot com 2010-08-21 06:22 ---
Index: gcc.target/i386/volatile-2.c
===
--- gcc.target/i386/volatile-2.c(revision 163421)
+++ gcc.target/i386/volatile-2.c(working copy)
@@ -1
--- Comment #8 from ubizjak at gmail dot com 2010-08-21 06:19 ---
Add:
/* { dg-require-effective-target nonpic } */
to the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-21 05:21
---
*** Bug 41323 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-21 05:21 ---
*** This bug has been marked as a duplicate of 45336 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-08-21
05:16 ---
Assembly created with...
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100820/gcc
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-08-21
05:15 ---
Created an attachment (id=21535)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21535&action=view)
assembly file for gcc.target/i386/volatile-2.c at -m32 on x86_64-apple-darwin10
--
http://gcc.gnu
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-21 05:13 ---
On Linux/Intel64, I got
time /usr/gcc-4.5/bin/gcc -m32 -O2 pr45364.i -g -c /tmp
/usr/gcc-4.5/bin/gcc -m32 -O2 pr45364.i -g -c 110.63s user 0.17s system 99%
cpu 1:50.87 total
[...@gnu-6 tmp]$ /usr/gcc-4.5/bin/
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-08-21
05:11 ---
The fix at r163416 caused...
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_0(\\(%rip\\))?
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \t][^,]+,
obj_1(\\(%rip\\))?
FAIL:
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-08-21
04:20 ---
Fixed with...
Author: lcwu
Date: Fri Jul 23 22:20:45 2010
New Revision: 162492
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162492
Log:
Fix violations of self-assignment check in GCC source.
Mod
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-21 04:14 ---
(In reply to comment #2)
> How are they are not commutative with respect of the NaNs? Is it only when
> both are operands are NaNs, it causes an issue?
>
Yes, only when both operands and NaNs with SSE FP.
--
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-21 04:10 ---
(In reply to comment #2)
> How are they are not commutative with respect of the NaNs? Is it only when
> both are operands are NaNs, it causes an issue?
>
>
> If I read your testcase correctly, x87 and SSE both d
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-21 03:58 ---
How are they are not commutative with respect of the NaNs? Is it only when
both are operands are NaNs, it causes an issue?
If I read your testcase correctly, x87 and SSE both don't do IEEE FP correctly
with resp
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-21 03:54 ---
[...@gnu-6 intrin]$ cat mulpd.c
#include
#include
#include
#include
__m128d a;
__m128d b;
uint64_t av[] = {0x0, 0xfff8ULL};
uint64_t bv[] = {0xffefULL, 0x7fff2d4db6efd985ULL};
uint64_t ex
According to table 4-7 in chapter 4, Vol 1 of
IA32/Inte64 SDM, x86 FP add and multiply aren't
commutative with Qnan/Snan inputs. But we have
DEF_RTL_EXPR(PLUS, "plus", "ee", RTX_COMM_ARITH)
DEF_RTL_EXPR(MULT, "mult", "ee", RTX_COMM_ARITH)
That impacts x86 FP plus and mult patterns. Should
we intr
--- Comment #52 from howarth at nitro dot med dot uc dot edu 2010-08-21
02:24 ---
Also the additional clarification that...
> The UnwindLevel1-gcc-ext.c source file in lldb is the same as in SnowLeopard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
--- Comment #2 from bero at arklinux dot org 2010-08-21 01:10 ---
Assumed it was an infinite loop a bit too early -- it did finish after giving
it some more time.
There is a speed problem though. Updating summary and severity.
--
bero at arklinux dot org changed:
What
--- Comment #1 from bero at arklinux dot org 2010-08-21 01:00 ---
Created an attachment (id=21534)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21534&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45364
Building the attached code with
gcc -m32 -O1 -g -c directx.i -o test.o
takes forever.
On a machine where
gcc -m32 -O0 -g -c directx.i -o test.o
finishes in 2.9 seconds and
gcc -m32 -O2 -c directx.i -o test.o
finishes in 15 seconds, I left
gcc -m32 -O2 -g -c directx.i -o test.o
running overnight
--- Comment #51 from howarth at nitro dot med dot uc dot edu 2010-08-21
00:55 ---
An additional clarification from the darwin unwinder developers on the status
of the libunwind sources from Snow Leopard...
> Everything down in the darwin layer is supposed to be open source. It was
> a
--- Comment #10 from tbptbp at gmail dot com 2010-08-21 00:49 ---
Subject: Re: pextr{b,w,d}, (worse than) redundant extensions
A quick check vs trunk tells me that not only pextr* are now sane but
about 2% movs*/movz* disappeared altogether (in that particular
binary).
Hat's off.
--
--- Comment #50 from howarth at nitro dot med dot uc dot edu 2010-08-21
00:31 ---
According to the darwin unwinder maintainers in the Snow Leopard libunwind
sources...
// The following functions are implemented to just call abort
_Unwind_GetDataRelBase
_Unwind_GetTextRelBase
_Unwind_Fi
--- Comment #3 from spop at gcc dot gnu dot org 2010-08-20 23:50 ---
Subject: Bug 45230
Author: spop
Date: Fri Aug 20 23:49:58 2010
New Revision: 163432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163432
Log:
Add testcase for PR45230.
2010-08-20 Sebastian Pop
PR
--- Comment #5 from changpeng dot fang at amd dot com 2010-08-20 22:48
---
I have a fix:
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01625.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
--- Comment #11 from burnus at gcc dot gnu dot org 2010-08-20 22:28 ---
(In reply to comment #7)
> Untested patch:
The patch is not sufficient as the following example shows for which no warning
is printed:
type t
end type t
type t2
integer :: j = 7
end type t2
contains
subroutine
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-08-20 22:00
---
It looks like the cc1 compiler is miscompiled. Which stage of the bootstrap is
this? Could you post a backtrace of cc1 from within gdb when it executes the
illegal instruction? Is that a recent problem on the 4
--- Comment #1 from gerald at pfeifer dot com 2010-08-20 21:22 ---
Created an attachment (id=21533)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21533&action=view)
Full sparc64-portbld-freebsd8.0/libgcc/config.log file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45363
This is the relevant part from sparc64-portbld-freebsd8.0/libgcc/config.log:
configure:3211: checking for suffix of object files
configure:3233: /usr/ports/lang/gcc45/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc45/work/build/./gcc/
-B/usr/local/sparc64-portbld-freebsd8.0/bin/
-B/usr/local/sparc64-p
--- Comment #9 from hjl at gcc dot gnu dot org 2010-08-20 20:58 ---
Subject: Bug 45336
Author: hjl
Date: Fri Aug 20 20:57:56 2010
New Revision: 163421
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163421
Log:
Cast to unsigned short/char first for _mm_extract_epi16/_mm_extract_e
--- Comment #8 from jakub at gcc dot gnu dot org 2010-08-20 20:54 ---
Subject: Bug 45336
Author: jakub
Date: Fri Aug 20 20:54:25 2010
New Revision: 163420
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163420
Log:
PR target/45336
* config/i386/sse.md (*sse4_1_pex
--- Comment #4 from ubizjak at gmail dot com 2010-08-20 20:49 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
Status|UNCONFIRMED |NEW
E
--- Comment #3 from uros at gcc dot gnu dot org 2010-08-20 19:24 ---
Subject: Bug 45361
Author: uros
Date: Fri Aug 20 19:23:52 2010
New Revision: 163416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163416
Log:
PR testsuite/45361
* gcc.target/i386/volatile-2.c:
--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-20 18:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
The issue is that for the push/pop macro the old state of the macro (a
cpp_macro reference) is stored. As this structure is handled by GC without a
root, all get free'ed when garbage collection happens.
This gc can lead to issues when such a saved node gets undefined and the node,
which previously
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-20 18:49 ---
Subject: Bug 44974
Author: jakub
Date: Fri Aug 20 18:49:46 2010
New Revision: 163415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163415
Log:
PR middle-end/44974
* builtins.c (expand_builtin)
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-20 18:35 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from nathan at gcc dot gnu dot org 2010-08-20 18:12 ---
Thanks Uros. Could you prepare a patch to match the x86_64 output -- given you
have the hardware?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45361
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-20 18:07 ---
Subject: Bug 45353
Author: jakub
Date: Fri Aug 20 18:07:12 2010
New Revision: 163412
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163412
Log:
PR rtl-optimization/45353
* sel-sched-ir.c (sel_b
--- Comment #1 from ubizjak at gmail dot com 2010-08-20 17:57 ---
This is testsuite problem, on x86_64 we have:
movl$0, obj_5(%rip)
movlobj_5(%rip), %eax
vs.
movl$0, obj_5
movlobj_5, %eax
on x86_32.
So, scan patterns should be updated
--- Comment #9 from burnus at gcc dot gnu dot org 2010-08-20 17:50 ---
(In reply to comment #8)
> Created an attachment (id=21532)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21532&action=view) [edit]
> Possibly final patch, though not yet regtested.
Fails for:
integer :: x(2)
On Linux/x86-64. revision 163402 gave
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \\t]obj_5,
--
Summary: gcc.target/i386/volatile-2.c failed
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #8 from burnus at gcc dot gnu dot org 2010-08-20 17:23 ---
Created an attachment (id=21532)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21532&action=view)
Run-time implementation
Possibly final patch, though not yet regtested.
--
burnus at gcc dot gnu dot org cha
The GCC manual (ARM Options) states that -mhard-float is "equivalent to
-mfloat-abi=hard". However that does seem to be the case when it comes to
linking:
$ arm-elf-gcc -mfloat-abi=hard -print-file-name=libc.a
/usr/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/fpu/libc.a
$ arm-elf-gcc -mhard-flo
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-20 16:54 ---
Created an attachment (id=21531)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21531&action=view)
A patch
I talked to icc people. They think the return value should be
zero-extended to reflex what hardware doe
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-20 16:02 ---
I think we certainly don't want to warn for = +, or =/**/+, so if anything,
there could be a warning for = token immediately followed by a token that makes
a valid = token (i.e. the same file, same line, column 1 above
C7 is a x86 CPU from VIA based on Esther (C5J) core evolved from the Nehemiah+
(C5P) core found in the C3-2 line.
/proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 10
model name : VIA Esther processor 800MHz
stepping: 9
cpu MHz
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-20 15:36 ---
Yes, "if (b = 2)" is valid and -Wparentheses warns about that.
(In reply to comment #0)
> It would be nice if future version could at least throw a warning.
Obviously it can't be anything *more* than a warning.
N.B.
--- Comment #2 from schwab at linux-m68k dot org 2010-08-20 15:35 ---
There is a lot of normal valid C we warn about...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
--- Comment #3 from dominiq at lps dot ens dot fr 2010-08-20 15:24 ---
With the patch in comment #2, some error messages are repeated several times:
for instance gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90 gives
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90:8
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-20 15:23 ---
=+ in x =+ y; isn't one token, but two, it is the same as if you write
x = + y ;
And, unary + is standard C unary operator:
The result of the unary + operator is the value of its (promoted) operand. The
integer promoti
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-20 15:13 ---
Created an attachment (id=21530)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21530&action=view)
gcc46-pr44974.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
Hello,
there is a minor issue when =+ is used by accident instead of +=.
It is unfortunate there there is not even a warning, because this is a typo
that can cost lots and lots of time.
Furthermore it seems that =+ is was the old syntax in the old pre ANSI C.
=+ behaves like =
(mathematically it
--- Comment #1 from hjl at gcc dot gnu dot org 2010-08-20 14:42 ---
Subject: Bug 45357
Author: hjl
Date: Fri Aug 20 14:42:28 2010
New Revision: 163405
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163405
Log:
Replace has_analyzed_clone with has_analyzed_clone_p.
2010-08-20 H.
On Linux/x86, revision 163403:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00616.html
gave:
../../src-trunk/gcc/lto/lto.c: In function 'lto_materialize_function':
../../src-trunk/gcc/lto/lto.c:161:3: error: implicit declaration of function
'has_analyzed_clone' [-Werror=implicit-function-declaration
Commands needed:
echo "" > empty.h
gcc empty.h -o testcase.h.gch
echo '#include "testcase.h"' > testcase.c
gcc -fcompare-debug -save-temps testcase.c
Output:
testcase.c:1:22: error: one or more PCH files were found, but they were invalid
testcase.c:1:22: error: use -Winvalid-pch for more informati
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-20 13:52 ---
We are running out of stack in recursive call:
Program received signal SIGSEGV, Segmentation fault.
0x41bf3c90 in if_then_else_cond (x=0x23ef08d0,
ptrue=0x6ef88070, pfalse=0x6ef8
On Linux/ia64, revision 163389 gave
FAIL: gcc.c-torture/compile/pr43164.c -O2 (internal compiler error)
FAIL: gcc.c-torture/compile/pr43164.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/pr43164.c -O2 -flto (internal compiler error)
FAIL: gcc.c-torture/compile/pr43164.c -O2 -flt
--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-20 12:38 ---
Invalid.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-20 12:21 ---
Created an attachment (id=21529)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21529&action=view)
gcc46-pr45353.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-08-20
12:04 ---
Fixed with r163326.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-08-20
12:02 ---
Fixed with r162882.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
-
Command line:
$ gcc -O -fschedule-insns -fselective-scheduling -freorder-blocks-and-partition
-fprofile-generate gcc.dg/tree-prof/update-cunroll-2.c
$ rm *.gcda
$ ./a.out
$ gcc -O -fschedule-insns -fselective-scheduling -freorder-blocks-and-partition
-fprofile-use gcc.dg/tree-prof/update-cunroll-2.
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-08-20
11:45 ---
Fixed at graphite branch merge r163105 through r163174.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2010-08-20
11:39 ---
No breakage in current bootstrap.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
---
Command line:
$ gcc -O -fschedule-insns -fselective-scheduling testcase.c
Compiler output:
$ gcc -O -fschedule-insns -fselective-scheduling testcase.ctestcase.c: In
function 'foo':
testcase.c:4:1: internal compiler error: RTL check: expected elt 3 type 'B',
have '0' (rtx barrier) in sel_bb_head, a
--- Comment #1 from zsojka at seznam dot cz 2010-08-20 11:15 ---
Created an attachment (id=21528)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21528&action=view)
reduced testcase (from gcc.dg/vect/no-vfa-vect-43.c)
The first loop is not needed to reproduce the problem, it just ma
Command line:
$ gcc -O1 -frerun-cse-after-loop -ftree-vectorize -fschedule-insns
-fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-loops
-fprefetch-loop-arrays testcase.c
or
$ gcc -O3 -fschedule-insns -fschedule-insns2 -fselective-scheduling2
-fsel-sched-pipelining -funroll-
--- Comment #14 from hubicka at gcc dot gnu dot org 2010-08-20 10:23
---
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01544.html
has patch for empty constructor removal in middle end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307
--- Comment #10 from jv244 at cam dot ac dot uk 2010-08-20 08:57 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Error: Dummy 'x' at (1) cannot have an initializer
>
> Do you have a suggestion?
>
Error: Dummy argument 'x' at (1) cannot have the save attribute which is
implied
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-20 08:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from burnus at gcc dot gnu dot org 2010-08-20 08:45 ---
(In reply to comment #8)
> Error: Dummy 'x' at (1) cannot have an initializer
>
> I think this is easy to understand, an additional short message about why it
> can't have an initializer will be better.
Do you have
--- Comment #7 from burnus at gcc dot gnu dot org 2010-08-20 08:43 ---
Comparison of the recurrence version with calling the library every time
(for the run-time library, I expect a similar result for MPFR/compile time
version):
http://gcc.gnu.org/ml/fortran/2010-08/msg00252.html
--
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-20 08:43 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-20 08:41 ---
Subject: Bug 45344
Author: jakub
Date: Fri Aug 20 08:41:00 2010
New Revision: 163397
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163397
Log:
PR fortran/45344
Backport from mainline
2
--- Comment #6 from abel at gcc dot gnu dot org 2010-08-20 08:07 ---
Subject: Bug 44691
Author: abel
Date: Fri Aug 20 08:07:17 2010
New Revision: 163396
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163396
Log:
PR rtl-optimization/44691
* gfortran.dg/pr44691.f:
76 matches
Mail list logo
