Fwd: Fusing two loops
-- Forwarded message --
From: Sandeep Maram [EMAIL PROTECTED]
Date: Thu, Apr 10, 2008 at 11:57 AM
Subject: Re: Fusing two loops
To: Zdenek Dvorak [EMAIL PROTECTED]
Hi Zdenek,
I have written this function
/* The following function fuses two loops. */
void
fuse_loops (struct loop *loop_a, struct loop *loop_b)
{
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
block_stmt_iterator bsi_a = bsi_start (loop_a-header);
block_stmt_iterator bsi_b = bsi_last (loop_b-header);
bsi_move_before (bsi_a, bsi_b);
fprintf (stderr, transferred one statement from loop %d to loop %d
, loop_a-num, loop_b-num);
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
cancel_loop_tree (loop_a);
}
It moved one statement from loop_a to loop_b. In the same way I must
tranfer all other statements too. I get a internal compiler error at
cancel_loop_tree(loop_a); . After transfering statemnts from loop_a
to loop_b I need to delete the loop_a from current_loops . How can we
do this?
Thanks,
Sandeep.
On Fri, Apr 4, 2008 at 7:31 PM, Zdenek Dvorak [EMAIL PROTECTED] wrote:
Hi,
I am trying to fuse two loops in tree level. For that, I am trying to
transfer statements in the header of one loop to the header of the
other one.
The codehttp://rafb.net/p/fha0IG57.html contains the 2 loops.
After moving a statement from one BB to another BB, do I need to
update any other info?
you will need to update SSA form; other than that, just using bsi_move_after
to move the relevant statements should work.
I need to transfer all the statements of bb_6 to bb_3. Can any one
please tell me what is the exact procedure.
Can i simply use add_bb_to_loop() and add bb_6 to loop_1 ?
No; in the case that you describe, moving the statements one by one is
probably the simplest way (you could also move whole basic block, but
it is more complicated, and since you still need to update SSA form,
you would need to process the statements anyway).
Zdenek
Doubt about scheduling
Hello all, I got few doubts regarding the way in which scheduling works in gcc 4.1.2 1. Will barrier insns gets scheduled along with other instructions? 2. When there is an unconditional jump in the instruction list, a barrier instruction gets emitted after the unconditional jump as the last instruction. Will this be regarded as an instruction when counting the number of instructions in a region for scheduling purposes? 3. After the end of scheduling a region can barrier remain as the last instruction in the ready list unscheduled? Or in other words can ready list be 'non-empty' after scheduling a region? Regards, Shafi
Re: more m32c brokenness
On Wed, Apr 9, 2008 at 10:40 PM, DJ Delorie [EMAIL PROTECTED] wrote: I tracked it down to this: /* Allow conversions between integral types and pointers only if there is no sign or zero extension involved. */ if (((POINTER_TYPE_P (type) INTEGRAL_TYPE_P (TREE_TYPE (op))) || (POINTER_TYPE_P (TREE_TYPE (op)) INTEGRAL_TYPE_P (type))) TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (op))) return false; The code does not do what the comment says. It also requires that there be no truncation. However, of course, other parts of the compiler complain about truncation as well. The root cause is this: ptr = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (ptr), ptr, fold_convert (sizetype, vtable)); We fold_convert to sizetype, without regard for whether it's the same precision as TREE_TYPE (ptr). vtable is the right size, ptr is the right size, but we're creating an intermediate that's the wrong size. Can we put in a calculate-unsigned-for-type call here? That should be sizetype for everyone else, but the special type for m32c. This particular case indeed needs fixing (I assume vtable is a pointer). There is build_nonstandard_integer_type for this. Richard.
Mapping back to original variables after SSA optimizations
Hi all, i have a doubt about unSSA: is it allways possible to map back the versioned variables to the original variable? If it could be possible, is there an algorithm that describe this translation back? I have read the paper Efficiently computing static single assignment form and the control dependence graph (cytron91) and no way to translate back from SSA is explained, it only points out that after SSA optimizations dead code elminitation and allocation by colloring are recommended to be performed. Thanks Fran
Re: Fusing two loops
Hi,
The error is rectified. The bug is in the function that calls fuse_loops().
Now I am trying to transfer all the statements, using code -
/* The following function fuses two loops. */
void
fuse_loops (struct loop *loop_a, struct loop *loop_b)
{
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
block_stmt_iterator bsi_a = bsi_start (loop_a-header);
block_stmt_iterator bsi_a_last = bsi_last (loop_a-header);
block_stmt_iterator bsi_b = bsi_last (loop_b-header);
while (bsi_a != bsi_a_last)
{
bsi_move_before (bsi_a, bsi_b);
fprintf (stderr, transferred one statement from loop %d to
loop %d , loop_a-num, loop_b-num);
bsi_next (bsi_a);
}
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
cancel_loop_tree (loop_a);
}
After doing this I get a segmentation fault , after 3 statements of
loop_a are transferred to loop_b.
Program received signal SIGSEGV, Segmentation fault.
0x08436245 in tsi_next (i=0xb5b0) at ../../trunk/gcc/tree-iterator.h:74
74i-ptr = i-ptr-next;
Thanks,
Sandeep.
On Thu, Apr 10, 2008 at 5:57 PM, Zdenek Dvorak [EMAIL PROTECTED] wrote:
Hi,
I have written this function
/* The following function fuses two loops. */
void
fuse_loops (struct loop *loop_a, struct loop *loop_b)
{
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
block_stmt_iterator bsi_a = bsi_start (loop_a-header);
block_stmt_iterator bsi_b = bsi_last (loop_b-header);
bsi_move_before (bsi_a, bsi_b);
fprintf (stderr, transferred one statement from loop %d to loop %d
, loop_a-num, loop_b-num);
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
cancel_loop_tree (loop_a);
}
It moved one statement from loop_a to loop_b. In the same way I must
tranfer all other statements too. I get a internal compiler error at
cancel_loop_tree(loop_a);
where exactly (can you send me a backtrace)? It does not seem possible
for cancel_loop_tree to ICE, if fuse_loops is the only function that you
call.
Zdenek
I wished to write to you
Hello!!! I find your email in internet and I wished to write to you. You do not know me... and I do not know you. But I trust in destiny and I hope that destiny give me a chance I want to find a kind, honest and clever man. My name - Natalya. My age-26 years.It is difficult to tell about myself. If this is of any interest to you, write to me I hope, I can see your letter soon. In the following letter I to tell about myself and send my photos. Write on my personal email: [EMAIL PROTECTED] now I write with the work and my chief does not know about it. Sincerely, Natalya.
Re: US-CERT Vulnerability Note VU#162289
Gerald,
Here is another version of the program (same compiler version/flags).
#include stdio.h
void test_signed(char *buf) {
signed int len;
len = 130;
printf(buf = %p; buf+len = %p; buf+len buf = %d %d,
buf, buf+len, buf+len buf, (uintptr_t)buf+len (uintptr_t)buf);
if((buf+len buf) != ((uintptr_t)buf+len (uintptr_t)buf))
printf( BUG!);
printf(\n);
}
void test_unsigned(char *buf) {
unsigned int len;
len = 130;
printf(buf = %p; buf+len = %p; buf+len buf = %d %d,
buf, buf+len, buf+len buf, (uintptr_t)buf+len (uintptr_t)buf);
if((buf+len buf) != ((uintptr_t)buf+len (uintptr_t)buf))
printf( BUG!);
printf(\n);
}
int main(void) {
test_signed(0);
test_signed((char*)0x7000);
test_signed((char*)0xf000);
test_unsigned(0);
test_unsigned((char*)0x7000);
test_unsigned((char*)0xf000);
return 0;
}
output:
buf = ; buf+len = 4000; buf+len buf = 0 0
buf = 7000; buf+len = B000; buf+len buf = 0 0
buf = F000; buf+len = 3000; buf+len buf = 1 1
buf = ; buf+len = 4000; buf+len buf = 0 0
buf = 7000; buf+len = B000; buf+len buf = 0 0
buf = F000; buf+len = 3000; buf+len buf = 1 1
The unsigned test was one we performed on the gcc versions. I added the
signed test, but it didn't make a difference on Visual Studio. My
understanding is that it shouldn't, because the real issue here is
pointer arithmetic and the resulting type should always be a pointer.
rCs
Robert C. Seacord wrote:
void f(char *buf) {
unsigned int len = len = 0xFF00;
if (buf+len buf) puts(true);
}
You need to be more precise. That is not the same example
that you quoted for GCC.
In fact, if you vary the criteria too much, you will find
situations where GCC already behaved that way. The test in
the following example is optimized out by old versions of
GCC (certainly my version 3.4.5 compiler does it, with no
warnings even when using -Wall):
int f(char *buf, int i)
{
i = 130;
if ((int)buf + i (int)buf)
return 0;
return 1;
}
That's quite a bit less changed than your example, which
brings unsigned-ness into the picture. [This is exactly
the problem--signed overflow and pointer overflow aren't
defined, unlike unsigned overflow.]
Given that current Microsoft compilers reportedly exhibit
this behavior, it sounds like the advisory is going to at
least need some significant rewriting. :-)
-Jerry
Re: Problem with reloading in a new backend...
Le mercredi 09 avril 2008 à 18:21 -0400, DJ Delorie a écrit :
Maybe I should reserve a special register for this usage (say r0).
That might be the only way, yes.
Ok, I reserved r0 (BP_REGNUM) for such reloads, and I'm generating new
instructions in LEGITIMIZE_RELOAD_ADDRESS to calculate the memory
address:
if (GET_CODE (*x) == PLUS
GET_CODE (XEXP (*x, 0)) == REG
GET_CODE (XEXP (*x, 1)) == CONST_INT) {
rtx reginsn, setinsn, plusinsn;
reginsn = gen_rtx_REG(Pmode, BP_REGNUM);
setinsn = gen_rtx_SET(Pmode, reginsn, XEXP (*x, 1));
plusinsn = gen_rtx_SET(Pmode, reginsn, gen_rtx_PLUS(Pmode,
reginsn, XEXP (*x, 0)));
emit_insn_before(setinsn, insn);
emit_insn_before(plusinsn, insn);
*x = reginsn;
return 1;
}
Does this sound ok ?
Note that I needed to use emit_insn_before() in order to insert the
instructions, and emit_insn_before() needs the current 'insn', which
is not passed by LEGITIMIZE_RELOAD_ADDRESS(), so I needed to modify the
macro. Is there something I miss here ?
Note that reload also assumes that such adds don't change the flags
(i.e. a compare/jump pair must not have a flag-modifying add between
them).
I think this won't happen because I emit the compare/conditional branch
insn at the same time, in beq/bne/bgt... etc define_insn() (like many
other targets).
Thanks.
--
Stelian Pop [EMAIL PROTECTED]
Re: Fusing two loops
Hi,
The error is rectified. The bug is in the function that calls fuse_loops().
Now I am trying to transfer all the statements, using code -
/* The following function fuses two loops. */
void
fuse_loops (struct loop *loop_a, struct loop *loop_b)
{
debug_loop (loop_a, 10);
debug_loop (loop_b, 10);
block_stmt_iterator bsi_a = bsi_start (loop_a-header);
block_stmt_iterator bsi_a_last = bsi_last (loop_a-header);
block_stmt_iterator bsi_b = bsi_last (loop_b-header);
while (bsi_a != bsi_a_last)
{
bsi_move_before (bsi_a, bsi_b);
fprintf (stderr, transferred one statement from loop %d to
loop %d , loop_a-num, loop_b-num);
bsi_next (bsi_a);
}
try
bsi_b = bsi_last (loop_b-header);
for (bsi_a = bsi_start (loop_a-header); !bsi_end_p (bsi_a); )
{
if (some condition) /* you probably want to skip labels and cond_exprs */
bsi_move_before (bsi_a, bsi_b);
else
bsi_next (bsi_a);
}
Zdenek
Re: Problem with reloading in a new backend...
Le jeudi 10 avril 2008 à 15:48 +0200, Stelian Pop a écrit :
Le mercredi 09 avril 2008 à 18:21 -0400, DJ Delorie a écrit :
Maybe I should reserve a special register for this usage (say r0).
That might be the only way, yes.
Ok, I reserved r0 (BP_REGNUM) for such reloads, and I'm generating new
instructions in LEGITIMIZE_RELOAD_ADDRESS to calculate the memory
address:
[...]
Now it seems that the register moves are correctly dealt with, but I'm
still having the same problem on calls: just like indirect addressing,
indirect calls are allowed only on even registers.
My patterns look like:
(define_insn *icall_value
[(set (match_operand 0 register_operand =r)
(call (mem:QI (match_operand:QI 1 register_operand z))
(match_operand:QI 2 )))]
icall (%1)
[(set_attr cc none)]
)
(define_expand call_value
[(set (match_operand 0 register_operand =r)
(call (match_operand:QI 1 memory_operand m)
(match_operand:QI 2 general_operand )))]
{
if (GET_CODE (XEXP(operands[1], 0)) != REG)
XEXP(operands[1], 0) = force_reg (QImode, XEXP
(operands[1], 0));
}
)
This gives:
(insn 27 26 29 2 ../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:564
(set (reg/f:QI 114)
(symbol_ref:QI (__lshrqi3) [flags 0x41])) 1 {*movqi}
(expr_list:REG_EQUIV (symbol_ref:QI (__lshrqi3) [flags 0x41])
(nil)))
...
(call_insn/u 30 29 31 2
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:564 (set (reg:QI 4 r4)
(call (mem:QI (reg/f:QI 114) [0 S1 A16])
(const_int 0 [0x0]))) 37 {*icall_value} (expr_list:REG_DEAD
(reg:QI 5 r5)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:QI 5 r5))
(expr_list:REG_DEP_TRUE (use (reg:QI 4 r4 [ D.2373 ]))
(nil
And r114 gets reloaded into r1:
Reloads for insn # 30
Reload 0: reload_in (QI) = (symbol_ref:QI (__lshrqi3) [flags 0x41])
EIGHT_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (reg/f:QI 114)
reload_reg_rtx: (reg:QI 1 r1)
Which does not satisfy the *icall_value constraints:
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function
‘__mulhi3’:
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:570: error: insn does
not satisfy its constraints:
(call_insn/u 30 195 162 2
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:564 (set (reg:QI 4 r4)
(call (mem:QI (reg:QI 1 r1) [0 S1 A16])
(const_int 0 [0x0]))) 37 {*icall_value}
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:QI 5 r5))
(expr_list:REG_DEP_TRUE (use (reg:QI 4 r4 [ D.2373 ]))
(nil
It seems that this reload doesn't pass through LEGITIMIZE_ADDRESS or
LEGITIMIZE_RELOAD_ADDRESS... How can I specify here to choose an EVEN_REGS
in place of the EIGHT_REGS (in fact it should choose one register in the
intersection of EIGHT and EVEN_REGS) ?
Thanks,
--
Stelian Pop [EMAIL PROTECTED]
GCC 4.2.4 Status Report (2008-04-10)
Status == The GCC 4.2 branch is open for commits under normal release branch rules. All fixes going on that branch should first have gone on trunk and 4.3 branch. I propose to build 4.2.4-rc1 once we have resolved what if any changes related to strict-overflow and pointer arithmetic should go on the branch. Any further 4.2 releases after 4.2.4 may depend on whether there is expressed user and developer interest in further releases from this branch, or whether 4.3 has been widely adopted in place of 4.2. Quality Data Priority # Change from Last Report --- --- P1 230 P2 137 + 2 P3 38 - 3 --- --- Total 198 - 1 Previous Report === http://gcc.gnu.org/ml/gcc/2008-03/msg01080.html I will send the next report for the 4.2 branch when making the 4.2.4-rc1 release candidate. -- Joseph S. Myers [EMAIL PROTECTED]
address taken problem
In the following code I marked the tree 'node.0' as address taken using
'c_mark_addressable'. Now in the assembly code, isn't the return value of the
second call to malloc completely discarded?
This problem does not arise in -O0. Here I'm using -O2.
main ()
{
void * D.2897;
struct node * D.2898;
struct node * node.0;
void * D.2900;
int * D.2901;
int * D.2902;
struct node * node;
D.2897 = malloc (8);
D.2898 = (struct node *) D.2897;
node = D.2898;
node.0 = node;
D.2900 = malloc (4);
D.2901 = (int *) D.2900;
node.0-item = D.2901;--
node.0 = node;
D.2902 = node.0-item;
printf (%p %p\n[0], D.2902, node);
}
main:
.LFB5:
subq $24, %rsp
.LCFI0:
movl $8, %edi
call malloc
movl $4, %edi
movq %rax, 16(%rsp)
call malloc
movq 16(%rsp), %rax
leaq 16(%rsp), %rdx
movl $.LC0, %edi
movq (%rax), %rsi
xorl %eax, %eax
call printf
addq $24, %rsp
ret
The code that is generated when I do not modify the flag.
main:
.LFB5:
pushq %rbx
.LCFI0:
movl $8, %edi
subq $16, %rsp
.LCFI1:
call malloc
movl $4, %edi
movq %rax, %rbx
movq %rax, 8(%rsp)
call malloc
movq %rax, (%rbx)
movq 8(%rsp), %rax
leaq 8(%rsp), %rdx
movl $.LC0, %edi
movq (%rax), %rsi
xorl %eax, %eax
call printf
addq $16, %rsp
popq %rbx
ret
thanks,
-- dasarath
Re: Doubt about scheduling
Mohamed Shafi [EMAIL PROTECTED] writes: I got few doubts regarding the way in which scheduling works in gcc 4.1.2 1. Will barrier insns gets scheduled along with other instructions? The scheduler works over regions. It doesn't look at barriers. 2. When there is an unconditional jump in the instruction list, a barrier instruction gets emitted after the unconditional jump as the last instruction. Will this be regarded as an instruction when counting the number of instructions in a region for scheduling purposes? It shouldn't. 3. After the end of scheduling a region can barrier remain as the last instruction in the ready list unscheduled? Or in other words can ready list be 'non-empty' after scheduling a region? As far as I know barriers won't get onto the ready list. If you see otherwise when running the compiler, then I am wrong. Ian
Re: Problem with reloading in a new backend...
(call (mem:QI (match_operand:QI 1 register_operand z)) Are you sure your z constraint only matches even numbered hard registers?
Re: Problem with reloading in a new backend...
Le jeudi 10 avril 2008 à 15:30 -0400, DJ Delorie a écrit :
(call (mem:QI (match_operand:QI 1 register_operand z))
Are you sure your z constraint only matches even numbered hard
registers?
Well, I think so:
enum reg_class
{
NO_REGS,
BP_REGS,
STACK_REGS,
EIGHT_REGS,
EVEN_REGS,
GENERAL_REGS,
ALL_REGS,
LIM_REG_CLASSES
};
#define N_REG_CLASSES ((int) LIM_REG_CLASSES)
#define REG_CLASS_CONTENTS \
{ \
{ 0x }, \
{ 0x0001 }, \
{ 0x8000 }, \
{ 0x00FF }, \
{ 0x }, \
{ 0x7FFE }, \
{ (1LL FIRST_PSEUDO_REGISTER) - 1 }\
}
...
(define_register_constraint z EVEN_REGS
Even registers (r0,r2,r4, @dots{} r30))
--
Stelian Pop [EMAIL PROTECTED]
Re: Problem with reloading in a new backend...
I noticed Stack register is missing from ALL_REGS. Are registers 16bit? Is just one required for pointer? Andy
Re: Problem with reloading in a new backend...
Le jeudi 10 avril 2008 à 15:56 -0400, [EMAIL PROTECTED] a écrit : I noticed Stack register is missing from ALL_REGS. No, it is not. It is missing from GENERAL_REGS but not from ALL_REGS. Are registers 16bit? Yes. Is just one required for pointer? For now, yes, I chose to support only 2^16 RAM addresses. In fact, this microcontroller is able to address 2^24, and two registers are used for indirect accesses (Rx and Rx+1, where x is even), this is the reason why only even registers are allowed in indirect addressing... -- Stelian Pop [EMAIL PROTECTED]
gcc-4.3-20080410 is now available
Snapshot gcc-4.3-20080410 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080410/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 134179 You'll find: gcc-4.3-20080410.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080410.tar.bz2 C front end and core compiler gcc-ada-4.3-20080410.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080410.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080410.tar.bz2 C++ front end and runtime gcc-java-4.3-20080410.tar.bz2 Java front end and runtime gcc-objc-4.3-20080410.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080410.tar.bz2The GCC testsuite Diffs from 4.3-20080403 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
A doubt about constraint modifiers
Hello all, I have noticed that when strict_low_part is used in a patten we need to use '+' as the constraint modifier if any constraints are used in the patterns. Why is this so? Regards, Shafi
[Bug preprocessor/35326] [4.2/4.3/4.4 regression] ICE with stray digraph token
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-04-10 06:16 --- I can still reproduce it with trunk, 4.3 branch and 4.2 branch from 2008-04-07. I can't reproduce it on x86_64, though (no segfault, no valgrind error). Did you try adding random characters before %:%: ? Maybe this changes memory layout so much that you see the segfault, too. Concerning comment #3: I cannot imagine that pfile-buffer was 0 from the beginning. It looks as if something trampled on the memory later. (I'd have to check that, though.) That would also explain the totally different error in the original report (and why you don't run into trouble with the same testcase). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35326
[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory
--- Comment #7 from charlet at gcc dot gnu dot org 2008-04-10 06:21 --- reopening -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-10 06:21:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880
[Bug tree-optimization/35821] Internal compiler error: segmentation fault
--- Comment #10 from irar at il dot ibm dot com 2008-04-10 07:10 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35821
[Bug tree-optimization/35869] ICE in calc_dfs_tree at -O2 -gnatp after VRP optimization
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-10 10:31 --- *** Bug 35894 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||marcus at jet dot franken ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35869
[Bug tree-optimization/35894] ICE in calc_dfs_tree, at dominance.c:393
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-10 10:31 --- *** This bug has been marked as a duplicate of 35869 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35894
[Bug tree-optimization/34006] [4.2 Regression] vectorization with 64-bit integers
--- Comment #6 from victork at gcc dot gnu dot org 2008-04-10 10:36 ---
The problem in reduced testcase is that loop gets vectorized by gcc 4.2 despite
a dependency between iterations with distance 1.
compute_data_dependences_for_loop () returns chrec_known for DDR {
ivec(iclass), ivec(iclass-1) }.
Here is part of dump produced by scev in 4.2:
(compute_affine_dependence
(stmt_a =
D.1282_9 = (*ivec_8)[D.1281_7])
(stmt_b =
(*ivec_8)[D.1280_6] = D.1284_13)
(subscript_dependence_tester
(analyze_overlapping_iterations
(chrec_a = {0, +, 1}_1)
(chrec_b = {1, +, 1}_1)
(analyze_siv_subscript
(analyze_subscript_affine_affine
(overlaps_a = scev_known)
(overlaps_b = scev_known)
)
)
(overlap_iterations_a = scev_known)
(overlap_iterations_b = scev_known)
)
(dependence classified: scev_known)
)
)
While in gcc 4.3 the scev produces the following dump for same DDR:
(compute_affine_dependence
(stmt_a =
D.970_9 = (*ivec_8(D))[D.969_7])
(stmt_b =
(*ivec_8(D))[D.968_6] = D.972_13)
(subscript_dependence_tester
(analyze_overlapping_iterations
(chrec_a = {0, +, 1}_1)
(chrec_b = {1, +, 1}_1)
(analyze_siv_subscript
(analyze_subscript_affine_affine
(overlaps_a = [1 + 1 * x_1]
)
(overlaps_b = [0 + 1 * x_1]
)
)
)
(overlap_iterations_a = [1 + 1 * x_1]
)
(overlap_iterations_b = [0 + 1 * x_1]
)
)
(analyze_overlapping_iterations
(chrec_a = 0B)
(chrec_b = 0B)
(analyze_ziv_subscript
)
(overlap_iterations_a = [0]
)
(overlap_iterations_b = [0]
)
)
(build_classic_dist_vector
dist_vector = ( 1
)
)
)
)
Sebastian, can you take a look?
Thanks.
--
victork at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
AssignedTo|victork at gcc dot gnu dot |spop at gcc dot gnu dot org
|org |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34006
[Bug c++/35898] C++ exception bug at run time when mutually recursive functions
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-10 10:40 --- Your exception specification on small, medium and large makes throws from the recursively called dummy_test bogus. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35898
[Bug c/35899] New: ICE on filesystem code
I get an ICE on some filesystem code I'm developing when trying to compile it with GCC 4.3.0. [EMAIL PROTECTED]:~/gcc-bug$ gcc-4.3 -v -save-temps -o sfs_unittests.o -O2 -g -I. -std=c99 -Wall -W -c sfs_unittests.c Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080401 (prerelease) (Debian 4.3.0-3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sfs_unittests.o' '-O2' '-g' '-I.' '-std=c99' '-Wall' '-W' '-c' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.1/cc1 -E -quiet -v -I. sfs_unittests.c -mtune=generic -std=c99 -Wall -W -fworking-directory -O2 -fpch-preprocess -o sfs_unittests.i ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.3.1/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: . /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.3.1/include /usr/lib/gcc/i486-linux-gnu/4.3.1/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sfs_unittests.o' '-O2' '-g' '-I.' '-std=c99' '-Wall' '-W' '-c' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.1/cc1 -fpreprocessed sfs_unittests.i -quiet -dumpbase sfs_unittests.c -mtune=generic -auxbase-strip sfs_unittests.o -g -O2 -Wall -W -std=c99 -version -o sfs_unittests.s GNU C (Debian 4.3.0-3) version 4.3.1 20080401 (prerelease) (i486-linux-gnu) compiled by GNU C version 4.3.1 20080401 (prerelease), GMP version 4.2.2, MPFR version 2.3.1. warning: GMP header version 4.2.2 differs from library version 4.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c8e3951360ed7273beac0a50e7fd5f3d In file included from sfs_unittests.c:4: fs/sfs_xplatform.h: In function sfs_write_file: fs/sfs_xplatform.h:130: warning: implicit declaration of function sfs_native_write_block fs/sfs_xplatform.h:148: warning: implicit declaration of function sfs_native_read_block sfs_unittests.c: At top level: sfs_unittests.c:5: warning: conflicting types for sfs_native_write_block fs/sfs_xplatform.h:130: warning: previous implicit declaration of sfs_native_write_block was here sfs_unittests.c:11: warning: conflicting types for sfs_native_read_block fs/sfs_xplatform.h:148: warning: previous implicit declaration of sfs_native_read_block was here sfs_unittests.c: In function printbl: sfs_unittests.c:18: warning: implicit declaration of function printf sfs_unittests.c:18: warning: incompatible implicit declaration of built-in function printf sfs_unittests.c: In function main: sfs_unittests.c:64: warning: incompatible implicit declaration of built-in function printf fs/sfs_xplatform.h: In function sfs_remove_bytes: fs/sfs_xplatform.h:250: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. [EMAIL PROTECTED]:~/gcc-bug$ -- Summary: ICE on filesystem code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: megari at mbnet dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35899] ICE on filesystem code
--- Comment #1 from megari at mbnet dot fi 2008-04-10 12:09 --- Created an attachment (id=15464) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15464action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35900] New: typecast (sign extension) missing
In the following example the typecast (sign extension) from int
(32bit) to long (64bit) is missing. Before the compare the signed i1
is 0 and unsigned u2 is 0 and this should be kept when casting to
64bit long. Same issue for long long (also 64bit).
So we get correct ov=1 with gcc version = 4.2, but wrong ov=0 with
gcc version = 4.3.
This issue occurs with and without optimization.
gcc version: gcc-4_3_branch and trunk svn revision 133752
(gcc-4_2 and below runs fine)
int main()
{
int ov;
unsigned u2;
int i1;
i1 = 0;
u2 = (unsigned)2147483647 + 1 ;
(i1) += (u2);
if ( (long)(i1)(long)(u2) ) ov = 1; else ov = 0;
return !ov;
}
--
Summary: typecast (sign extension) missing
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holger dot hopp at sap dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35900
[Bug middle-end/35897] DSE doesn't support targets with wide registers
--- Comment #3 from hjl dot tools at gmail dot com 2008-04-10 13:32 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00837.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg00837.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35897
[Bug c/35900] typecast (sign extension) missing
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-10 13:45 --- I belive this was fixed by Author: rguenth Date: Tue Apr 8 22:03:33 2008 New Revision: 134110 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134110 Log: 2008-04-08 Richard Guenther [EMAIL PROTECTED] * fold-const.c (fold_widened_comparison): Do not allow sign-changes that change the result. * gcc.c-torture/execute/20080408-1.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/20080408-1.c - copied unchanged from r134108, trunk/gcc/testsuite/gcc.c-torture/execute/20080408-1.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35900
[Bug middle-end/35897] DSE doesn't support targets with wide registers
--- Comment #4 from hjl at gcc dot gnu dot org 2008-04-10 14:06 --- Subject: Bug 35897 Author: hjl Date: Thu Apr 10 14:05:52 2008 New Revision: 134163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134163 Log: 2008-04-09 H.J. Lu [EMAIL PROTECTED] PR middle-end/35897 * dse.c (store_info): Add a FIXME for positions_needed. (fill_bitmask): New. (record_store): Assert width = size of positions_needed * CHAR_BIT. Call fill_bitmask to initialize positions_needed. (check_mem_read_rtx): Use long on mask. Call fill_bitmask to set mask. Modified: branches/ix86/avx/gcc/ChangeLog.avx branches/ix86/avx/gcc/dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35897
[Bug ada/35902] New: xml ada installation bug in slackware
Hi, Hi, I have installed gnat-gpl on my Linux machine. And then from the same directory under sources folder I extracted the xml-ada library. And started to install it. I executed the configure command successfully. But then I tried to make by executing make -f Makefile.314 install command. Then after a series of normal output the execution was interrupted. And I observed the following output. .. cc -c -I./ -I../../unicode -I../../input_sources -I../../sax -I../../dom -I../ -O2 -gnatN -I- ../../sax/sax-attributes.adb +===GNAT BUG DETECTED==+ | 3.3.6 (i486-slackware-linux-gnu) in expand_call, at calls.c:3098 | | Error detected at /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/adainclude/s-secsta.ads:65:14| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | concatenated together with no headers between files. | +==+ Please include these source files with error report ../../sax/sax-attributes.adb ../../sax/sax-attributes.ads ../../sax/sax.ads ../../unicode/unicode.ads ../../unicode/unicode-ces.ads ../../sax/sax-models.ads ../../unicode/unicode.adb ../../unicode/unicode-names.ads ../../unicode/unicode-names-basic_latin.ads ../../unicode/unicode-names-latin_extended_a.ads compilation abandoned gnatmake: ../../sax/sax-attributes.adb compilation error make[1]: *** [sax-attributes.o] Error 4 make[1]: Leaving directory `/mnt/IS/olya/gnat-gpl/x86-linux/sources/xmlada-2.1/sax' make: *** [sax] Error 2 -- Summary: xml ada installation bug in slackware Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: olcay dot alic at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35902
[Bug ada/35902] xml ada installation bug in slackware
--- Comment #1 from charlet at gcc dot gnu dot org 2008-04-10 14:41 --- You should probably report this to slackware then. Note that you are not using gnat gpl in your report, but a very old GCC version (3.3.6), so I'd suggest trying with a newer version, where things will very likely work. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35902
[Bug c/35900] typecast (sign extension) missing
--- Comment #2 from holger dot hopp at sap dot com 2008-04-10 16:15 --- You're right! Great - the fix is faster available than expected! Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35900
[Bug c++/35331] [4.3/4.4 regression] ICE with invalid specialization of variadic template
--- Comment #2 from pcarlini at suse dot de 2008-04-10 17:05 --- Seems doable... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #15 from jakub at gcc dot gnu dot org 2008-04-10 17:40 --- The i?86 Linux kernel just got bitten by this again, see https://bugzilla.redhat.com/show_bug.cgi?id=427707 In this case, it wasn't about a tail call, but I believe high register pressure that caused modification of the incoming stack slot, which is undesirable for kernel asmlinkage functions. The #c14 patch after small fixup (s/preserve-stack/preserve_stack/) fixes some cases, but certainly all, on the other side pessimizes code even where it is not strictly necessary (though it is unclear how hard would it be to improve that). On f1 already vanilla gcc doesn't modify the incoming stack area, and the patch just pessimizes it by reading all arguments into registers and then storing them into a different stack slot, eventhough d argument is actually never modified and so could be used directly from the stack slot, avoiding one move from memory and one move to memory. f2 is an example where the patch doesn't help at all, and incoming stack area is modified even with the patch. On f3 the patch properly prevents doing tail call, as that would actually modify the incoming stack area. But on f4 there is no need to avoid the tail call. I guess we could live with avoiding all tail calls, but a) need a fix for f2 b) for f1 I'd say at expand time for -O1+ we should know whether an argument is TREE_ADDRESSABLE or not, and whether it is ever modified or not, which could help us avoid unnecessary copying. Still will need to make sure reloading won't push anything into the incoming registers area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack on ia32/x86_64
--- Comment #16 from jakub at gcc dot gnu dot org 2008-04-10 18:09 --- From the kernel people it would be interesting to hear on which targets they actually need it (e.g. if it is i?86 only, it would be better implemented as i?86 specific syscall_linkage attribute). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack on ia32
--- Comment #17 from jakub at gcc dot gnu dot org 2008-04-10 18:13 --- x86_64 actually isn't a problem, as it passes integral arguments in registers (and kernel only uses at most 6 syscall arguments). Structures aren't passed by value. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|no way to stop gcc from |no way to stop gcc from |mucking with the incoming |mucking with the incoming |argument stack on |argument stack on ia32 |ia32/x86_64 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug c/35903] New: false warning when passing quoted string to function strcmp(arg,no);
When building libm-test.c (part of the GLIBC make check math test suite for GLIBC CVS head as of April 10, 2008) with GCC 4.3 I get the following warning: math/libm-test.c: In function 'parse_opt': math/libm-test.c:6102: warning: array subscript is above array bounds In relation to the following code: if (strcmp (arg, yes) == 0) This warning goes away if replaced with: char yes[] = yes; if (strcmp (arg,yes) == 0) Andrew Pinski says this is a false warning and that I should file a bug report. -- Summary: false warning when passing quoted string to function strcmp(arg,no); Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rsa at us dot ibm dot com GCC build triplet: n/a GCC host triplet: n/a GCC target triplet: n/a http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903
[Bug c/35903] false warning when passing quoted string to function strcmp(arg,no);
--- Comment #1 from rsa at us dot ibm dot com 2008-04-10 18:57 --- Created an attachment (id=15465) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15465action=view) preprocessed test-ildouble.c file. strcmp on line 16036 seems to be the problematic one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903
[Bug c/35903] false warning when passing quoted string to function strcmp(arg,no);
--- Comment #2 from rsa at us dot ibm dot com 2008-04-10 18:58 --- Compiled with: cd /home/ryanarn/glibc/stages/stage_lround/glibc/math /opt/at43/bin/gcc -m32 test-ildoubl.c -save-temps -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -mcpu=power4 -mlong-double-128 -mnew-mnemonics -Wstrict-prototypes -mlong-double-128 -Wno-uninitialized -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -I../include -I/home/ryanarn/glibc/stages/stage_lround/build/glibc32_power4/math -I/home/ryanarn/glibc/stages/stage_lround/build/glibc32_power4 -I../sysdeps/powerpc/powerpc32/elf -I../sysdeps/powerpc/elf -I../sysdeps/unix/sysv/linux/powerpc/powerpc32/power4/fpu -I../sysdeps/powerpc/powerpc32/power4/fpu -I../sysdeps/unix/sysv/linux/powerpc/powerpc32/power4 -I../sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu -I../sysdeps/powerpc/powerpc32/fpu -I../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../nptl/sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/ieee754/ldbl-128ibm -I../sysdeps/ieee754/ldbl-opt -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/powerpc -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/powerpc/powerpc32/power4 -I../sysdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32 -I../sysdeps/powerpc/fpu -I../sysdeps/powerpc/math -I../nptl/sysdeps/powerpc -I../sysdeps/powerpc -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio -I. -nostdinc -isystem /opt/at43/lib/gcc/powerpc64-linux/4.3.0/include -isystem /opt/at43/lib/gcc/powerpc64-linux/4.3.0/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -U__LIBC_INTERNAL_MATH_INLINES -D__FAST_MATH__ -DTEST_FAST_MATH -fno-builtin -o /home/ryanarn/glibc/stages/stage_lround/build/glibc32_power4/math/test-ildoubl.o -MD -MP -MF /home/ryanarn/glibc/stages/stage_lround/build/glibc32_power4/math/test-ildoubl.o.dt -MT /home/ryanarn/glibc/stages/stage_lround/build/glibc32_power4/math/test-ildoubl.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35903
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #4 from jaydub66 at gmail dot com 2008-04-10 21:09 --- To me it's also not completely clear what the standard says on this, but the way to fix it would probably be to insert some additional check into operator_correspondence (interface.c), where currently only the type and rank of the arguments is checked. To require full equality of all array borders (as suggested in my comment #2), one could simply add if (!gfc_compare_array_spec (f1-sym-as, f2-sym-as)) return 1; into the above mentioned routine. This would result in gfortran behaving the same way as ifort in this case, may it be standard-conforming or not. If on the other hand Tobias is right in the assumption he made in comment #3, then one could something along the lines of if (f1-sym-as-type != f2-sym-as-type) return 1; to require only the array types to be equal, or something similar to at least prevent assumed-shape arrays from being passed instead of eplicit-shape arrays. My feeling is that at least the array size should match for explicit-shape arrays, but this is just a feeling and I couldn't find anything in the standard to confirm this. I'm not sure if the changes I'm suggesting would interfere with any other case where 'operator_correspondence' is called, but at least they don't seem to trigger any regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug c++/35904] New: Poor error message
The code:
void grab(int i);
int main(void)
{ grab(1); }
Produces the useful and informative error:
invalid initialization of non-const reference of type int from a temporary
of type int
Whereas the code:
templatetypename T
void grab(T t, int i);
int main(void)
{ grab(1,1); }
Produces the much less useful
no matching function for call to grab(int, int)
Would it be possible to still get the error message about temporaries in the
templated case?
--
Summary: Poor error message
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35904
[Bug target/35768] gcc.c-torture/compile/20010226-1.c:22: ICE: in do_output_reload, at reload1.c:7331
--- Comment #8 from danglin at gcc dot gnu dot org 2008-04-10 22:51 --- Subject: Bug 35768 Author: danglin Date: Thu Apr 10 22:50:49 2008 New Revision: 134182 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134182 Log: PR target/35768 * pa.md: Define mode iterator P. Define mode attribute dwc. (dcacheflush): Update pattern to use iterator P and attribute dwc. (icacheflush): Likewise. * pa.h (INITIALIZE_TRAMPOLINE): Use dcacheflushsi/icacheflushsi if !TARGET_64BIT, and dcacheflushdi/icacheflushdi if TARGET_64BIT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.h trunk/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35768
[Bug target/35768] gcc.c-torture/compile/20010226-1.c:22: ICE: in do_output_reload, at reload1.c:7331
--- Comment #9 from danglin at gcc dot gnu dot org 2008-04-10 22:52 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35768
[Bug other/35905] New: gcc 4.2.3 still contains many GPL v2 references
I just downloaded GCC 4.2.3, and discovered that it states in several places that it's using GPL v2 instead of v3; my impression from following the mailing lists is that it (and even 4.2.2) should be GPL v3. One example (a particularly important one, since it's most exposed to the user) is the manual: http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Copying.html#Copying. Also, the top-level directory of the source contains v2 versions of COPYING and COPYING.LIB. (I don't know what, if any, files within the tree refer to the top-level versions of those files, instead of the versions within subdirectories, but it is at the very least confusing to only have v2 versions at the top level.) Another example I ran across is that files in libstdc++/src refer to GPL v2. (Though, given the presence of the exception there, there's probably little difference between v2 and v3...) -- Summary: gcc 4.2.3 still contains many GPL v2 references Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlton at bactrian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35905
[Bug other/35905] gcc 4.2.3 still contains many GPL v2 references
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-10 23:17 --- (Though, given the presence of the exception there, there's probably little difference between v2 and v3...) Actually this is why those have not been moved yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35905
[Bug other/35905] gcc 4.2.3 still contains many GPL v2 references
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-10 23:19 --- (In reply to comment #1) Actually this is why those have not been moved yet. And more to the point, the FSF lawyers have not decided how to word the exception for the GPLv3. Now Copying.html is a different story and I think was already fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35905
[Bug other/35905] gcc 4.2.3 still contains many GPL v2 references
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-10 23:20 --- (In reply to comment #2) Now Copying.html is a different story and I think was already fixed. And has: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00106.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35905
[Bug other/35905] gcc 4.2.3 still contains many GPL v2 references
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-10 23:21 --- I don't think we should keep this bug opened any more as the only issue left to fix is really in the FSF hands and they are already working on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35905
[Bug other/35905] gcc 4.2.3 still contains many GPL v2 references
--- Comment #5 from carlton at bactrian dot org 2008-04-10 23:30 ---
Thanks for the info. I just did a spot check on the trunk and
4.2 branch: it looks like all the currently fixable issues I raised are fixed
in the trunk, and Copying.html is probably fixed in the branch (I saw
gpl_v3.texi). But there's no COPYING3{,.LIB} at the toplevel
of the 4.2 branch, which I think is important to reduce confusion.
I didn't spot check the 4.3 or 4.1 branches. (Is 4.1 still open?
I don't remember.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35905
[Bug c++/19476] Missed null checking elimination with new
--- Comment #12 from ian at airs dot com 2008-04-10 23:33 --- Note that bug 35878, which was closed as a duplicate of this one, was a case of placement new. For placement new the check for a NULL pointer is particularly useless, as the language standard says that placement new is required to return the pointer which was passed in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
[Bug other/35905] gcc 4.2.3 still contains many GPL v2 references
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-10 23:34 ---
(Is 4.1 still open? I don't remember.)
Yes but no see the thread starting at
http://gcc.gnu.org/ml/gcc/2008-03/msg00163.html .
4.3 branch should be have already COPYING3{,.LIB} as it was the trunk when they
were added.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35905
[Bug c++/35884] defining __need_size_t before including cstddef causes error
--- Comment #2 from stdin at stdin dot me dot uk 2008-04-11 03:36 --- You define __need_size_t when you want to pull in the definition of size_t but not other typedefs/functions. It's the standard way to get the size_t type. -- stdin at stdin dot me dot uk changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35884
