The error is:
/home/eric/gnat/gnat-head/native32/./gcc/xgcc
-B/home/eric/gnat/gnat-head/native32/./gcc/
-B/home/eric/install/gnat-head/i586-suse-linux/bin/
-B/home/eric/install/gnat-head/i586-suse-linux/lib/ -isystem
/home/eric/install/gnat-head/i586-suse-linux/include -isystem
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-08-06 06:21
---
Created an attachment (id=21420)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21420action=view)
Preprocessed file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
--- Comment #5 from paolo dot carlini at oracle dot com 2010-08-06 06:53
---
*** This bug has been marked as a duplicate of 42032 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from paolo dot carlini at oracle dot com 2010-08-06 06:53
---
*** Bug 45202 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #68 from bonzini at gnu dot org 2010-08-06 07:07 ---
fwprop.c doesn't handle it directly, but local_ref_killed_between_p should see
defs created by df-scan.c for each hard register in regs_invalidated_by_call
(see df_get_call_refs).
Also, since fwprop can lengthen lifetimes
--- Comment #2 from felipe dot contreras at gmail dot com 2010-08-06 07:08
---
(In reply to comment #1)
? (you have to give some more details)
What exactly do you need?
From the manpage
LIBRARY_PATH
The value of LIBRARY_PATH is a colon-separated list of directories, much like
We have problems with GCC-4.5.0 and GCC-4.5.1 for ARM when using the -Os
optimizer flag. The code crashes due to what seems to be undefined instruction
exception.
If we instead use -O1 or -O2 it works fine. Also GCC-4.3.x and GCC-4.4.x
works well.
I also tried to add all excluded -O2 flags when
--- Comment #1 from fredrik dot hederstierna at securitas-direct dot com
2010-08-06 07:20 ---
Created an attachment (id=21421)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21421action=view)
Script to build arm-elf toolchain
--
--- Comment #52 from dominiq at lps dot ens dot fr 2010-08-06 07:33 ---
The miscompilation with -m64 is back at revision 162879.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #8 from dominiq at lps dot ens dot fr 2010-08-06 07:46 ---
The test works here with:
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--- Comment #9 from dominiq at lps dot ens dot fr 2010-08-06 07:49 ---
to upgrade your system to 10.5 or 10.6?
I just realized that 10.6 requires an Intel proc!-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-06 07:52 ---
Have you tried compiling with -fno-strict-aliasing ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When compiling the code-snippet below with powerpc-*-gcc -msdata,
this error happens:
# powerpc-rtems4.11-gcc -c test.c -o test.o -msdata
test.c:10: error: rtems_filesystem_mount_table_size causes a section type
conflict
--- snip ---
int pipe (int __fildes[2] );
void Init( void )
{
int fd[2]
--- Comment #2 from rahul at icerasemi dot com 2010-08-06 08:01 ---
Confirmed, fix for PR41317 avoids forwarding ARRAY_REFs to their use and fixes
this issue. Does this fix hinder any optimizations?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45195
--- Comment #3 from fredrik dot hederstierna at securitas-direct dot com
2010-08-06 08:36 ---
(In reply to comment #2)
Have you tried compiling with -fno-strict-aliasing ?
I've tried it now, and it made no difference I'm afraid.
The code got slightly bigger, but behavior is the same
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2010-08-06 09:05
---
(In reply to comment #8)
Hmm. I've now built gfortran 4.5.1 20100521 (from the branch) and still have
the same internal compiler error.
I have gcc 4.5.1 20100506 on x86_64-apple-darwin10.3.0, and it
--- Comment #4 from fredrik dot hederstierna at securitas-direct dot com
2010-08-06 09:09 ---
Hm, I now tried to disable all possible optimization flags, but still -Os
does not work, but -O2 still works!
Does the -Os option do anything more that is not controllable from command
line
--- Comment #5 from ramana at gcc dot gnu dot org 2010-08-06 09:13 ---
If you don't give us a testcase we can't verify / see what's going wrong here.
Please report bugs as described here. http://gcc.gnu.org/bugs/ .
Thanks,
Ramana
--
ramana at gcc dot gnu dot org changed:
--- Comment #69 from bernds at gcc dot gnu dot org 2010-08-06 09:29 ---
(In reply to comment #68)
Also, since fwprop can lengthen lifetimes arbitrarily (though this wouldn't
happen often) propagate_rtx actually forbids copy propagation of hard
registers:
if (REG_P (new_rtx)
--- Comment #70 from bonzini at gnu dot org 2010-08-06 09:54 ---
The real reason is the first: why is there no def for r25?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #71 from bernds at codesourcery dot com 2010-08-06 09:57
---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On 08/06/2010 11:54 AM, bonzini at gnu dot org wrote:
--- Comment #70 from bonzini at gnu dot org 2010-08-06 09:54 ---
The real
--- Comment #72 from bonzini at gnu dot org 2010-08-06 10:00 ---
No, why is there no def for r25 _where it is clobbered_?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #73 from bernds at codesourcery dot com 2010-08-06 10:27
---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On 08/06/2010 12:00 PM, bonzini at gnu dot org wrote:
--- Comment #72 from bonzini at gnu dot org 2010-08-06 10:00 ---
No, why is
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-06 10:28 ---
We need a testcase. Also please try -fno-strict-aliasing if you know the
code is bogus.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-06 10:37 ---
Works for me on x86_64-linux with -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-06 11:06 ---
Confirmed.
struct _Unwind_Context { void *ra; };
void _Unwind_RaiseException(void)
{
struct _Unwind_Context this_context, cur_context;
long offset = uw_install_context_1 ((this_context), (cur_context));
void
--- Comment #18 from dominiq at lps dot ens dot fr 2010-08-06 11:08 ---
AFAICT this pr seems to have been fixed between revisions 162881 (fail) and
162920 (OK) at least on x86_64-apple-darwin10.4.0 (-m32 and -m64) and
powerpc-apple-darwin9 (-m32, see
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-06 11:11 ---
Confirmed.
Program received signal SIGSEGV, Segmentation fault.
0x00b6a1e4 in gimple_bb (g=0x0)
at /space/rguenther/src/svn/trunk/gcc/gimple.h:1148
1148 return g-gsbase.bb;
(gdb) up
#1
--- Comment #6 from fredrik dot hederstierna at securitas-direct dot com
2010-08-06 12:06 ---
Yes you are right, unfortunately I just had problems to break out any small
test case from our sources.
I think I found out what is the source of the problems.
The -Os disable alignment of
--- Comment #19 from dominiq at lps dot ens dot fr 2010-08-06 12:48 ---
From IRC:
martinj dominiq: r162911 and r162912 ...and no other recent change seems
relevant
martinj dominiq: whether the bug is fixed or just hidden, I can't really
tell at the moment
--
dominiq at lps dot ens
Hello,
I have coredump for exception handling in a c++ program using dynamic library.
I wrote the minimal application using dlopen to load a libtest_so.so and
execute functions in so with dlsym. In the libtest_so.so I throw an exception
and try to catch it.
Source code:
1) main application
--- Comment #1 from skylanderr at gmail dot com 2010-08-06 13:14 ---
Created an attachment (id=21422)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21422action=view)
the preprocessed file for tha application
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45209
--- Comment #2 from skylanderr at gmail dot com 2010-08-06 13:15 ---
Created an attachment (id=21423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21423action=view)
the preprocessed file for the library
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45209
--- Comment #2 from contact at philipashmore dot com 2010-08-06 13:37
---
It's exactly what I tried first - I know there are obvious cases as per your
frequently reported bugs section.
I wanted the compiler to tell me where the aliasing was occurring in these and
in
any less obvious
--- Comment #74 from bonzini at gnu dot org 2010-08-06 13:38 ---
Thanks for the help. I'll look at it tomorrow/next week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #3 from contact at philipashmore dot com 2010-08-06 13:52
---
Maybe I should add that the 0.6.0-beta1 release in GIT passed uintptr_t - sized
structures by value and the compiler spotted the aliasing, which is why I
introduced the pointer - uintptr_t - pointer hacks to
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-06 13:55 ---
(In reply to comment #3)
Maybe I should add that the 0.6.0-beta1 release in GIT passed uintptr_t -
sized
structures by value and the compiler spotted the aliasing, which is why I
introduced the pointer -
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-06 14:08 ---
Works on x86_64-linux. I suspect that linking libgcc and libgcc_eh statically
causes the problem for you as I can reproduce the segfault when linking
the whole test application statically. Thus, this sounds like
--- Comment #14 from dschlic1 at gmail dot com 2010-08-06 14:35 ---
Subject: Make fails in zlib
Hello;
Can you put that in layman's terms? I am using the standard GNU
linker and assembler. I run Ubuntu 10.04 LTS with all of the latest
patches.
Thank You,
Donald Schlicht
On Thu,
--- Comment #4 from redi at gcc dot gnu dot org 2010-08-06 15:36 ---
The committee is currently in the middle of re-designing future::get so I'll
wait and see what happens. It looks as though it's going to be renamed and
throw if called twice.
--
redi at gcc dot gnu dot org
A subroutine fails to compile with an apparently incorrect error message. It is
a piece of the scientific software called nextnano3. I will attach it to this
bug.
--
Summary: compilation error
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
--- Comment #1 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:43
---
Created an attachment (id=21424)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21424action=view)
p1.f90
first part of the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
--- Comment #2 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:45
---
Created an attachment (id=21425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21425action=view)
second part of the test case
This file contains to routines. The error is reported in the first one, but
--- Comment #3 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:49
---
To reproduce:
1. gfortran -c p1.f90 (no message)
2. gfortran -c p2.f90
p2.f90:66.25:
CALL ijk_to_i_j_k(i_j_k,i_j_k_fid,grid_size)
1
Error: Rank mismatch in argument 'j' at (1)
gfortran (all versions 4.2-4.5) reports the error when trying to compile code
below:
Error: Type 'link_info' at (1) is a parameter to the BIND(C) procedure
'liter_cb' but is not C interoperable because derived type 'info_t' is not C
interoperable
when I remove the module and compile just the
--- Comment #23 from mikael at gcc dot gnu dot org 2010-08-06 17:17 ---
Subject: Bug 44660
Author: mikael
Date: Fri Aug 6 17:17:37 2010
New Revision: 162949
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162949
Log:
2010-08-06 Mikael Morin mik...@gcc.gnu.org
PR
--- Comment #24 from mikael at gcc dot gnu dot org 2010-08-06 17:19 ---
One more down
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rwild at gcc dot gnu dot org 2010-08-06 17:22 ---
(In reply to comment #14)
Can you put that in layman's terms?
Yes; sorry for the complicated and technical response. As far as I can see,
there is at the moment no simple way to avoid this issue with a
--- Comment #4 from dominiq at lps dot ens dot fr 2010-08-06 17:22 ---
Confirmed on 4.4.4 and 4.5.0, but the test compiles with trunk (with/without
-fno-whole-file). Now I see:
...
CALL ijk_to_i_j_k(i_j_k,i_j_k_fid,grid_size)
...
SUBROUTINE ijk_to_i_j_k(i,j,k,size,i_j_k)
The call
--- Comment #1 from dominiq at lps dot ens dot fr 2010-08-06 17:26 ---
Confirmed also with trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45211
--- Comment #5 from sliwa at blue dot cft dot edu dot pl 2010-08-06 18:07
---
Your right, I assumed blindly that this code makes at least some sense (I
modified it to remove the dependencies, but the main issue remains the same).
However, it compiles with Pathscale 3.1 and SunStudio
--- Comment #6 from dominiq at lps dot ens dot fr 2010-08-06 18:42 ---
Your right, I assumed blindly that this code makes at least some sense (I
modified it to remove the dependencies, but the main issue remains the same).
However, it compiles with Pathscale 3.1 and SunStudio 12.1
--- Comment #15 from ubizjak at gmail dot com 2010-08-06 19:33 ---
This one started to fail on mainline recently.
f:
.frame $30,0,$26,0
.prologue 0
lda $1,18($16)
ldq_u $0,18($16)
extbl $0,$1,$0
ret $31,($26),1
.end f
The
--- Comment #7 from siarhei dot siamashka at gmail dot com 2010-08-06
19:36 ---
Do you have any packed structs? I wonder if the problem could be somehow
related to PR45070. But it's hard to say anything until you narrow down the
problem to a smaller testcase.
--
siarhei dot
--
ubizjak at gmail dot com changed:
What|Removed |Added
Summary|[4.0/4.1 regression]|[4.6 Regression] generates
|generates code that
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-08-06 19:45
---
Can you instead open a new bug please? Thx.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
gcc.target/alpha/PR24178.c started to fail on mainline recently:
FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18(
The problem is, that we don't generate expected ldl insn, but:
f:
.frame $30,0,$26,0
.prologue 0
lda $1,18($16)
ldq_u $0,18($16)
--- Comment #17 from ubizjak at gmail dot com 2010-08-06 20:00 ---
(In reply to comment #16)
Can you instead open a new bug please? Thx.
Sure. PR45212.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
--- Comment #1 from ubizjak at gmail dot com 2010-08-06 20:14 ---
The problem is, that we enter alpha_expand_mov_nobwx with operand[1]:
(mem/s:QI (plus:DI (reg/v/f:DI 72 [ p10 ])
(const_int 18 [0x12])) [0+8 S1 A16])
This fails aligned_memory_operand (operands[1], mode) check.
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-06 20:29 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The attached source file gives:
$ gcc -c t.c -Os -fno-omit-frame-pointer
/tmp/ccAuCzVe.s: Assembler messages:
/tmp/ccAuCzVe.s:16: Error: suffix or operands invalid for `push'
It complains on the line:
pushq $0x3f80
Reproduced on:
Target: x86_64-pc-linux-gnu
Configured with:
--- Comment #1 from philip dot taylor at cl dot cam dot ac dot uk
2010-08-06 20:37 ---
Created an attachment (id=21426)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21426action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-06 20:44 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from john at quivinco dot com 2010-08-06 20:48 ---
I just read this...
TDM-GCC has been built to allow the use of GCC's -fopenmp option for
generating parallel code as specified by the OpenMP API. (See
http://gcc.gnu.org/onlinedocs/libgomp/ for details.) If you want to
--- Comment #3 from ubizjak at gmail dot com 2010-08-06 20:53 ---
(In reply to comment #0)
It complains on the line:
pushq $0x3f80
No, it doesn't. Assembler complains on:
pushq $0xbf80
Which makes this a binutils bug. Let's ask H.J.
--
ubizjak at gmail
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-06 21:02 ---
I opened:
http://www.sourceware.org/bugzilla/show_bug.cgi?id=11893
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from dominiq at lps dot ens dot fr 2010-08-06 21:09 ---
Thanks to Thomas König, the mystery is sorted out: both p1.f90 and p2.f90
contain a subroutine ijk_to_i_j_k. In p1 the subroutine has the right dummy
arguments for the call, while the one in p2 has wrong ones. Due to
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
The attached testcase, from gcc's own gimplify.c, is optimized poorly at the
tree stage. Initial RTL has
;; t_1-gsbase.plf = D.2014_8;
(insn 8 6 9 (set (reg:QI 65)
(mem/s:QI (plus:SI (reg/v/f:SI 58 [ t ])
(const_int 1 [0x1])) [0+1 S1 A8])) gimplify.i:48 -1
(nil))
--- Comment #1 from bernds at gcc dot gnu dot org 2010-08-06 21:21 ---
Created an attachment (id=21427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21427action=view)
A testcase which shows the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45214
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-06 21:24 ---
What's the plan with the patch of comment #2?
NB, the result of gfc_dep_compare_expr (l_start, r_start) could be cached
instead of computed twice:
+ ((res = gfc_dep_compare_expr (l_start, r_start)) == 0
+ ||
The following testcase
int x (int t)
{
if (t 256)
return -26;
return 0;
}
can be implemented as a sequence of two shifts and one and operation:
movl4(%esp), %eax
sall$23, %eax
sarl$31, %eax
andl$-26, %eax
ret
Initial RTL
--- Comment #4 from dominiq at lps dot ens dot fr 2010-08-06 21:34 ---
I am not to sure about the patch in comment #2 because the case should probably
be handled by gfc_is_same_range and the patch does it in
gfc_check_section_vs_section. Note that gfc_is_same_range has a line
/*
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-06 21:48 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-06 21:49 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-06 21:51 ---
The bug is in gcc. pushq $imm32S only takes 32bit signed extended
immediate. You can't push 0xbf80. Instead, you push -1082130432
or 0xbf80.
--
hjl dot tools at gmail dot com changed:
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-06 22:10 ---
This patch:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 204211a..3dfbede 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -12921,7 +12921,7 @@ ix86_print_operand (FILE
We have RROTATE_EXPR and LROTATE_EXPR, but the patterns are not reliably
detected at the tree level. I'm attaching a testcase reduced from the Linux
kernel, which has at least one sequence that can be rewritten using a rolw
instruction:
movzwl %cx, %edx
movzwl %ax, %eax
--- Comment #1 from bernds at gcc dot gnu dot org 2010-08-06 22:19 ---
Created an attachment (id=21428)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21428action=view)
A testcase which shows the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216
unsigned int bplpt;
void BPLPTH (unsigned short x)
{
bplpt = (bplpt 0x) | (x 16);
}
void BPLPTL (unsigned short x)
{
bplpt = (bplpt 0x) | x;
}
Here, nothing at the tree level recognizes that these functions implement
16-bit stores into a larger object. This is handled by the
--- Comment #14 from tkoenig at gcc dot gnu dot org 2010-08-06 22:33
---
Subject: Bug 45159
Author: tkoenig
Date: Fri Aug 6 22:33:37 2010
New Revision: 162966
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162966
Log:
2010-08-06 Thomas Koenig tkoe...@gcc.gnu.org
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-08-06 22:35 ---
Nice reduced testcase:
templatetypename T
struct remove_reference
{
typedef T type;
};
templatetypename TestType struct forward_as_lref{};
templatetypename Seq, typename N
struct apply1
{
typedef typename
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet|i686-pc-mingw32 |
Keywords||ice-on-valid-code
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-06 22:39 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00528.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Consider
a = (x / 39) * 32 + (x % 39)
If we have no instruction to produce both the quotient and the remaineder, this
can be computed as
y = x / 39
z = x - y * 39
a = y * 32 + z
The last line can be simplified by substituting:
a = y * 32 + x - y * 39
a = y * (32 - 39) + x
a = x - y
--- Comment #5 from dominiq at lps dot ens dot fr 2010-08-06 22:49 ---
Note that the following patch I have in my tree for some time now also fix the
pr
--- gcc/fortran/dependency.c2010-08-07 00:37:34.0 +0200
+++ ../work/gcc/fortran/dependency.c2010-08-05
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Command line:
$ gcc -O2 -fprofile-generate testcase.c
Valgrind output:
==8227== Invalid read of size 8
==8227==at 0x60BB4B: dominated_by_p (dominance.c:973)
==8227==by 0x950317: dse_enter_block (tree-ssa-dse.c:198)
==8227==by 0xF18CC6: walk_dominator_tree (domwalk.c:188)
==8227==
--- Comment #1 from zsojka at seznam dot cz 2010-08-06 23:00 ---
Created an attachment (id=21429)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21429action=view)
reduced testcase (from gcc.dg/tree-ssa/20041008-1.c)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-06 23:02 ---
pathetic... :)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from steven at gcc dot gnu dot org 2010-08-06 23:12 ---
Martin, perhaps a test case you want to watch if you or someone else is going
to play with SRA vs. bitfields.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-06 23:17 ---
Related to PR17886, where it says that: gcc can detect the (x y)|(x
(bitwidth-y)) idiom for rotate and convert it into the machine rotate
instruction. But it only works when y is a constant and is not long long.
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-08-06 23:23
---
Subject: Bug 44942
Author: ebotcazou
Date: Fri Aug 6 23:22:52 2010
New Revision: 162967
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162967
Log:
PR target/44942
* config/sparc/sparc.c
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-08-06 23:23
---
Subject: Bug 44942
Author: ebotcazou
Date: Fri Aug 6 23:23:12 2010
New Revision: 162968
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162968
Log:
PR target/44942
* config/sparc/sparc.c
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-08-06 23:23
---
Subject: Bug 44942
Author: ebotcazou
Date: Fri Aug 6 23:23:29 2010
New Revision: 162969
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162969
Log:
PR target/44942
* config/sparc/sparc.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-06 23:41 ---
Fold used to detect these. Maybe we're now having different conversions
inbetween.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-06 23:44 ---
Confirmed. BIT_FIELD_EXPR would be a good match for this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from dschlic1 at gmail dot com 2010-08-07 00:18 ---
Subject: Re: Make fails in zlib
Hello;
I changed the value of lt_cv_shlibpath_overrides_runpath (it was set to
the result of an equality statement). No joy. The log is attached.
Results from the terminal are:
++,objc,fortran,java,ada,obj-c++
Thread model: posix
gcc version 4.6.0 20100806 (experimental) [trunk revision 162948] (GCC)
Program received signal SIGSEGV, Segmentation fault.
0x0062ab88 in dominated_by_p (dir=CDI_DOMINATORS, bb1=0x7ae08e10, bb2=0x0)
at ../../gcc/gcc/dominance.c:973
973
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-07 00:32 ---
Looks related to PR 45219.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 109 matches
Mail list logo
