I'm not sure if all of these are within libgomp, definitely
some are, maybe all.
alphaev67-dec-osf5.1
=== libgomp tests ===
Schedule of variations:
unix
Running target unix
Using /home/jayk/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using
--- Comment #8 from linuxl4 at sohu dot com 2010-08-20 06:50 ---
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.
It helps if you already state (a) the error
--- 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=gccview=revrev=163396
Log:
PR rtl-optimization/44691
* gfortran.dg/pr44691.f:
--- 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=gccview=revrev=163397
Log:
PR fortran/45344
Backport from mainline
--- 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 #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 #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 a
--- 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 #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 by
--- 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
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
--- 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=21528action=view)
reduced testcase (from gcc.dg/vect/no-vfa-vect-43.c)
The first loop is not needed to reproduce the problem, it just
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,
--- 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
--- 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
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
--- 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
--- 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 #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=21529action=view)
gcc46-pr45353.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- 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
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
--- 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,
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 information
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'
--- 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=gccview=revrev=163405
Log:
Replace has_analyzed_clone with has_analyzed_clone_p.
2010-08-20
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
--- 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=21530action=view)
gcc46-pr44974.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- 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
--- 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
--- 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 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. at
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 #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 op= token (i.e. the same file, same line, column 1
--- 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=21531action=view)
A patch
I talked to icc people. They think the return value should be
zero-extended to reflex what hardware
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
--- 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=21532action=view)
Run-time implementation
Possibly final patch, though not yet regtested.
--
burnus at gcc dot gnu dot org
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:
--- 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=21532action=view) [edit]
Possibly final patch, though not yet regtested.
Fails for:
integer :: x(2)
--- 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 #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=gccview=revrev=163412
Log:
PR rtl-optimization/45353
* sel-sched-ir.c
--- 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 #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 #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=gccview=revrev=163415
Log:
PR middle-end/44974
* builtins.c (expand_builtin):
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 #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
--- 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=gccview=revrev=163416
Log:
PR testsuite/45361
* gcc.target/i386/volatile-2.c:
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
Status|UNCONFIRMED |NEW
--- 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
--- 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=gccview=revrev=163420
Log:
PR target/45336
* config/i386/sse.md
--- 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=gccview=revrev=163421
Log:
Cast to unsigned short/char first for
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/
--- 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=21533action=view)
Full sparc64-portbld-freebsd8.0/libgcc/config.log file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45363
--- 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
--- 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 #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 #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=gccview=revrev=163432
Log:
Add testcase for PR45230.
2010-08-20 Sebastian Pop
--- 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
--- 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 #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
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 #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=21534action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45364
--- 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 #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
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 introduce a
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-21 03:54 ---
[...@gnu-6 intrin]$ cat mulpd.c
#include stdlib.h
#include string.h
#include stdint.h
#include emmintrin.h
__m128d a;
__m128d b;
uint64_t av[] = {0x0, 0xfff8ULL};
uint64_t bv[] = {0xffefULL,
--- 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
--- 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 don't
--- 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 #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=gccview=revrev=162492
Log:
Fix violations of self-assignment check in GCC source.
--- 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\\))?
--- 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]$
--- 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=21535action=view)
assembly file for gcc.target/i386/volatile-2.c at -m32 on x86_64-apple-darwin10
--
--- 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 #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 #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
75 matches
Mail list logo
