--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-02 03:01 ---
Note I might have reduced this testcase too much as I remove the reference to
cik from the loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27870
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-02 02:54 ---
Confirmed, reduced testcase:
void mat_product(double **const b, unsigned m)
{
int j;
double cik = 0;
#pragma omp for reduction(+: cik)
for (j = 0; j < m; ++j)
;
}
So the reduction in general is causing it.
Th
--- Comment #1 from bowie dot owens at csiro dot au 2006-06-02 02:41
---
Created an attachment (id=11575)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11575&action=view)
pre-processed c++ code that triggers the ICE
Compiling I get the following:
foo.cc: In function 'void mat_pr
rsion 4.2.0 20060601 (experimental)
compiled with:
g++ -save-temps -c -fopenmp foo.cc
--
Summary: ICE in build_outer_var_ref, at omp-low.c:585 with openmp
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priorit
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-02 02:35 ---
if (DECL_INITIAL (decl) != NULL_TREE)
error ("duplicate label %qD", decl);
else
Maybe adding into the if condition:
POP_TIMEVAR_AND_RETURN (TV_NAME_LOOKUP, error_mark_node);
This might work but I have not
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-02 02:32 ---
The C front-end does not add the duplicated label to the IR while the C++
front-end does.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2 Regression] build |build failure on m68k:
|failure on m68k: error:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-02 02:25 ---
(In reply to comment #2)
> I'm CCing Andreas Schwab since he apparently ported ffi to m68k. I noticed
> that the part of the code that produces the error is within an ifdef
> USE_LIBFFI, so possibly disabling ffi on
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-02 02:21 ---
Confirmed on both GDR saying this is a bug and Paolo providing a patch to fix
this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-02 02:12 ---
g++f4 -o hello hello.o -lmudflap
You need both -fmudlfap and -lmudflap when linking.
This is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-02 00:48 ---
(define_insn "sse_vmaddv4sf3"
[(set (match_operand:V4SF 0 "register_operand" "=x")
(vec_merge:V4SF
(plus:V4SF (match_operand:V4SF 1 "nonimmediate_operand" "%0")
(match_operand
--- Comment #57 from jvdelisle at gcc dot gnu dot org 2006-06-02 00:17
---
Closing. I have regular testing on my list. Last I checked the gcc farm did
not have daily gcc builds going yet. I was keying off that because I did not
want to do my own builds on the garm. I will keep at it.
Consider the following C program using SSE intrinsics:
//--
#include
#include
int main(int argc, const char **argv) {
__m128 v;
v = _mm_setr_ps( 1.0f, 2.0f, 3.0f, 4.0f );
v = _mm_rsqrt_ss( v );
v = _mm_add_ss( v, _mm_movehl_ps( v, v ));
v = _mm_a
--- Comment #6 from idht4n at hotmail dot com 2006-06-01 23:03 ---
Still behaves the same in 4.1.1 20060525 (Red Hat 4.1.1-1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
--- Comment #22 from wilson at gcc dot gnu dot org 2006-06-01 22:36 ---
Subject: Bug 26483
Author: wilson
Date: Thu Jun 1 22:36:19 2006
New Revision: 114319
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114319
Log:
Fix broken denorm support.
PR libgcj/26483
* src/ia64/ffi.c (s
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-01 21:50 ---
*** Bug 27868 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-01 21:50 ---
You set your break point on exit in gdb and run your program and then you get
the backtrace and look where the problem comes from, There is no magic going on
with -fbounds-check
Anyways this is a dup of bug 23375.
--- Comment #15 from geoffk at gcc dot gnu dot org 2006-06-01 21:49 ---
After discussion with Mike, I don't think Andrew's fix is right either.
If varasm.c wants to be able to predict memory layout, then what it needs to do
is ensure that the memory layout is seen as a single unit by th
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-01 21:41 ---
> Why not use gdb?
I don't see how gdb helps pinpointing the array-out-of-bound problem. As said:
the program ends with
Fortran runtime error: Array reference out of bounds
Program exited with
--- Comment #3 from christophe dot jaillet at wanadoo dot fr 2006-06-01
21:37 ---
On my AMD Athlon and current HEAD and, I have other results, i.e. 2 or 3 times
FASTER :
(using your 19 bytes long 'aaa..' string)
stringfrom
lengthbuiltin library
(-O2)
--- Comment #1 from pcarlini at suse dot de 2006-06-01 21:37 ---
Gaby, I had a quick look and maybe it's just a trivial typo: the below seems
right to me and certainly fixes the testcase without regressions... What do you
think?
Thanks, Paolo.
//
Index: include/bits/valar
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-01 21:31 ---
Thanks for taking care of this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 21:30 ---
Why not use gdb?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27868
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-06-01 21:30
---
Yes, that makes sense -- in fact, it looks like altivec_vslw_v4sf can then be
removed as well. I'm currenly testing a patch to that effect ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
It is really helpful to have a program which stops with
Fortran runtime error: Array reference out of bounds
when compiled with -fbounds-check. Because one has no idea where this happens.
Expected: At least crash so that one can do a backtrace in the debugger. Or
write out the file/line numbe
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-06-01 21:09 ---
(In reply to comment #0)
> In the following program there is clearly a problem with the "r = d"
> assignment. In most real programs such drastic case does not happen. However,
> simple precision loss or worse things
On Mon, 29 May 2006, Karl Berry wrote:
> rms asked me to try systematize the Texinfo dir categories to match the
> Free Software Directory where possible. So I hope you will be ok
> with changing the gcc manuals to say
> @dircategory Software development
> instead of
> @dircategory Programming
>
--- Comment #2 from tbm at cyrius dot com 2006-06-01 20:01 ---
I'm CCing Andreas Schwab since he apparently ported ffi to m68k. I noticed
that the part of the code that produces the error is within an ifdef
USE_LIBFFI, so possibly disabling ffi on m68k would allow it to compile. But
ma
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-06-01 19:24
---
Subject: Bug 27715
Author: tkoenig
Date: Thu Jun 1 19:23:56 2006
New Revision: 114317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114317
Log:
2006-06-01 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-01 19:19 ---
I think that this one can be declared well and truly gone for the time
being.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-06-01 19:14
---
azuma% grep maxssiz /stand/system
tunable maxssiz 16777216
azuma% swapinfo
Kb Kb Kb PCT START/ Kb
TYPE AVAILUSEDFREE USED LIMIT RESERVE PRI NAME
dev 4194304 8
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-06-01 19:13 ---
(In reply to comment #3)
> This is now fixed on mainline provided the user specifies -ffast-math.
> There are some complications where imagpart(z*~z) can be non-zero, if
> imagpart(z) is non-finite, such as an Inf or
| Hello,
|
| I found some unexpected behavior in valarray, couldn't find anything
| previous referencing it, and I thought that I'd write before
| (erroneously??) submitting a bug.
|
| Simple case: repeated application of operator==
|
| Silly example:
|
| std::valarray v1(100,1);
| std::valarray v2
In the following program there is clearly a problem with the "r = d"
assignment. In most real programs such drastic case does not happen. However,
simple precision loss or worse things may occure.
gfortran -Wall should warn, but it does not deserve a default warning.
program test
double precisi
--- Comment #12 from whaley at cs dot utsa dot edu 2006-06-01 18:43 ---
Subject: Re: gcc 4 produces worse x87 code on all platforms than gcc 3
Uros,
>gcc version 3.4.6
>vs.
>gcc version 4.2.0 20060601 (experimental)
>
>-fomit-frame-pointer -O -msse2 -mfpmath=sse
&g
--- Comment #4 from trini at kernel dot crashing dot org 2006-06-01 18:36
---
(In reply to comment #3)
> Actually no, you have to use -fPIC to get this not to be optimized, otherwise
> func will be bound locally which is not what you want.
Two things. First, that's a change in behavio
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from janis at gcc dot gnu dot org 2006-06-01 17:50 ---
A regression hunt using an alpha-linux cross compiler on powerpc64-linux with
the testcase mini.c identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=113632
r113632 | sayle | 2006-05-08 21
--- Comment #1 from janis at gcc dot gnu dot org 2006-06-01 17:45 ---
Created an attachment (id=11574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11574&action=view)
minimized testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27865
FreePOOMA 2.4.1 fails to build on powerpc-linux with beginning with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=114057
r114057 | rakdver | 2006-05-24 22:55:15 + (Wed, 24 May 2006)
Output with a minimized testcase:
elm3b145% /opt/gcc-nightly/trunk/bin/g++ -c -O2 poomabug.cc
p
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-01 17:24 ---
And "yara" gets this correct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Bugs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 17:21 ---
Confirmed, this is a RA issue.
Before register allocation:
(insn:HI 10 7 11 2 (set (reg:SI 63)
(const_int 3 [0x3])) 34 {*movsi_1} (nil)
(expr_list:REG_EQUIV (const_int 3 [0x3])
(nil)))
(insn:HI 1
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-01 17:14 ---
Confirmed, a little more reduced testcase:
typedef unsigned int uint32_t;
union double_union
{
double d;
uint32_t i[2];
};
int *_Jv_s2b (void);
int *_Jv_Balloc (int);
double _Jv_strtod_r (int *ptr, char *se,
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-01 16:28 ---
I can reproduce this with 4.2.0 Mon May 29 22:03:29 UTC 2006 (revision 114217M)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
time CCing myself so
I don't have to retype everything :)
>gcc version 3.4.6
>vs.
>gcc version 4.2.0 20060601 (experimental)
>
>-fomit-frame-pointer -O -msse2 -mfpmath=sse
>
>There is a small performance drop on gcc-4.x, but nothing critical.
>
>I can confirm, that
--- Comment #10 from whaley at cs dot utsa dot edu 2006-06-01 16:02 ---
Created an attachment (id=11571)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11571&action=view)
Same benchmark, but with single precision timing included
Here's the same benchmark, but can time single as wel
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-01 15:57 ---
Reduced testcase:
long stack[100];
int main(int argc,char**argv,char **envp)
{
long *esp=stack;
static void* jarray[]={ &&KeyCtrlKV };
*++esp=(long)&&_loc0;
goto SetTermStruc;
_loc0:;
*++esp=(long)&&_loc1;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-01 15:50 ---
Created an attachment (id=11569)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11569&action=view)
testcase (unreduced)
Testcase. Reducing currently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
gcc -c -O2 e3.c
e3.c:1803: internal compiler error: in check_cfg, at haifa-sched.c:4615
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.suse.de/feedback> for instructions.
--
Summary: [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-06-01 15:44
---
(In reply to comment #11)
> Index: arith.c
> ===
> --- arith.c (revision 114111)
> +++ arith.c (working copy)
> @@ -1133,8 +1133,10 @@ gfc_c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work||3.4
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |target
Keywords||build, ice-on-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 15:26 ---
There is nothing special about reassociation at all. In fact what you are
seeing is register allocator going funky. This what you get with x87.
--
pinskia at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-06-01 15:23 ---
(In reply to comment #1)
> --with-headers with a combined build is not really a good thing.
>
--with-headers is required for cross compilers in order to build a working
libgcov. A working libgcov is required for pr
--- Comment #12 from mark at codesourcery dot com 2006-06-01 14:59 ---
Subject: Re: [4.1 Regression] num_ssa_names inconsistent
or immediate use iterator wrong
jakub at gcc dot gnu dot org wrote:
> --- Comment #11 from jakub at gcc dot gnu dot org 2006-06-01 11:48
> ---
> Do
--- Comment #12 from dje at gcc dot gnu dot org 2006-06-01 14:20 ---
*** Bug 27862 has been marked as a duplicate of this bug. ***
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from dje at gcc dot gnu dot org 2006-06-01 14:20 ---
dup
*** This bug has been marked as a duplicate of 27536 ***
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-01 14:17 ---
err, -O, not -O0 in previous comment. Obviously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27862
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-01 14:13 ---
Reproduces also with
/abuild/rguenther/obj/stage1-gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O0
-gnatpg -gnatO g-os_lib.o g-os_lib.adb -o /dev/null
-fno-section-anchors fixes it.
--
http://gcc.gnu.org/bugzilla/s
/gcc/abuild/rguenther/obj/stage1-gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O2 -W
-Wall -fPIC -g -mno-minimal-toc -gnatpg -gnatO g-os_lib.o g-os_lib.adb -o
/dev/null
+===GNAT BUG DETECTED==+
| 4.2.0 20060601 (experimental) (powerpc64-suse-linux-gnu
--- Comment #1 from tbm at cyrius dot com 2006-06-01 13:59 ---
Created an attachment (id=11567)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11567&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
I get the following ICE with gcc 4.2 20060508 and 20060530 on mipsel.
Actually, I get this with gcc 4.0 and 4.1 too. gcc 3.4 works.
sh-3.1# /usr/lib/gcc-snapshot/bin/gcc -c -O1 mini.c
mini.c: In function 'do_dror':
mini.c:56: internal compiler error: in expand_expr_real_1, at expr.c:6916
Please
The C compiler generates wrong assembler code for functions with __attribute__
((interrupt ("IRQ"))). Link register lr in interrupt function is decremented
two times before it is loaded back to the program counter pc. It is decremented
at the beginning of interrupt routime (sub lr, lr, #4) and
--- Comment #2 from tbm at cyrius dot com 2006-06-01 13:01 ---
Created an attachment (id=11566)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11566&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
--- Comment #1 from tbm at cyrius dot com 2006-06-01 13:00 ---
3012:[EMAIL PROTECTED]: ~/tmp/delta/bin]
/home/tbm/tmp/gcc/20060530-alpha/gcc/xgcc -c
-O1 mini.c
3013:[EMAIL PROTECTED]: ~/tmp/delta/bin]
/home/tbm/tmp/gcc/20060530-alpha/gcc/xgcc -c
-O2 mini.c
mini.c: In function _Jv_strt
I get the following ICE when bootstrapping gcc 4.2 20060530 on alpha. 20060508
worked fine. I'm running delta right now and will send a test case when it's
done.
/build/buildd/gcc-snapshot-20060530/build/./gcc/xgcc
-B/build/buildd/gcc-snapshot-20060530/build/./gcc/
-B/usr/lib/gcc-snapshot/alpha-
--- Comment #5 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-06-01
12:53 ---
Subject: RE: [4.1 only] fastjar is asking for makeinfo in gmake bootstrap
Sorry M. Pinski, I do not understand your comment. Do you mean fasjar is
removed from the pre-release and not in the tarballs?
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-01 12:40
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #6 from bonzini at gnu dot org 2006-06-01 12:33 ---
documentation committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #5 from bonzini at gnu dot org 2006-06-01 12:28 ---
Subject: Bug 25453
Author: bonzini
Date: Thu Jun 1 12:28:11 2006
New Revision: 114305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114305
Log:
2006-06-01 Paolo Bonzini <[EMAIL PROTECTED]>
PR 25453
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-06-01 12:22 ---
The SMT related stuff is a red herring.
Someone is not marking things for renaming when they should be.
The following patch will show that (it disables the used alone code).
Index: tree-ssa-operands.c
=
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-01 12:09 ---
Similar(?) bug on ppc for trunk:
+===GNAT BUG DETECTED==+
| 4.2.0 20060601 (experimental) (SUSE Linux) (powerpc64-suse-linux-gnu) GCC
error:|
| in
--- Comment #11 from jakub at gcc dot gnu dot org 2006-06-01 11:48 ---
Does the C++ FE need the exact decl after gimplification? If not, perhaps
as a workaround pushdecl_maybe_friend could together with duplicating DECL_UID
also populate a hash table and cp-gimplify.c would use that has
$ cat tmp.c
unsigned athird (unsigned val)
{
return val / 3;
}
$ /home/etienne/projet/toolchain/bin/gcc -S -Os -o tmp.s -fomit-frame-pointer
-fverbose-asm tmp.c
$ cat tmp.s
.file "tmp.c"
# GNU C version 4.1.1 (i686-pc-linux-gnu)
# compiled by GNU C version 4.1.1.
# GGC heurist
The testcase from PR target/27827 shows another problem, this time with
-ffast-math. The runtime performance of -ffast-math code drops for ~30%.
The problem could be traced down to reassociation tree pass, because the
performance jumps back when "flag_unsafe_math_optimizations" switch is disabled
--- Comment #2 from mckinlay at redhat dot com 2006-06-01 11:07 ---
This rule is mentioned in the last paragraph of JVMS, S 5.4.4:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#75929
It is explicitly stated that this is checked during verification, unlike
: 3191.917
cache size : 512 KB
shows even more interesting results:
gcc version 3.4.6
vs.
gcc version 4.2.0 20060601 (experimental)
-fomit-frame-pointer -O -msse2 -mfpmath=sse
GCC 3.x performance:
./xmm_gcc
ALGORITHM NB REPSTIME MFLOPS
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-01
08:17 ---
This is still the case; Is this a gfortran issue or a gcc one?
If I give the characters length, using any format, even the anonymous warning
goes away. In fact, any array expression that I have tried is
--- Comment #4 from mirko dot bruzzone at primeur dot com 2006-06-01 08:08
---
I tried to compile in another directory than the source directory and I
executed the make bootstrap...but nothing.
This is the report:
gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -W
--- Comment #56 from paul dot richard dot thomas at cea dot fr 2006-06-01
07:31 ---
Jerry,
Where are we with this one? Did you have time yet to automatize the testing?
It would be real nice to close it!
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
82 matches
Mail list logo
