Re: Problem with Fix for PR 35163 ?
Btw, I have a fix. oh gr8. I just saw your post on the gcc-patches. Do you still want me to add this to PR35163 for the record ? Cheers! Pranav
Re: more m32c brokenness
On Wed, Apr 9, 2008 at 3:28 AM, DJ Delorie [EMAIL PROTECTED] wrote: Continuation of the last one, different bug, building libstdc++ ... Look familiar to anyone? If not, I'll try to hunt down the cause. The culprit is this line: D.25530 = (unsigned int) D.25529; For m32cm, int is 16 bits, long is 32 bits, and void* is 24 bits. A cast to unsigned int truncates a pointer. What size is the internal 'sizetype'? Is there an integer type with the same width as the pointer type? Basically the problems look like converting a pointer to an integer always either extends or truncates which is both prohibited in the GIMPLE IL (as the pointer doesn't have a sign we don't know whether to sign- or zero-extend it). Richard. [ gdb ] up #3 0x085588ec in verify_gimple_2 (stmts=0xb6e7c738) at ../../gcc/gcc/tree-cfg.c:4126 4126bool err2 = verify_gimple_stmt (stmt); [ gdb ] call debug_generic_expr (stmts) D.25526 = this-D.17063._vptr.basic_ostream; D.25527 = *D.25526; D.25528 = D.25527 + -12; D.25529 = *D.25528; D.25530 = (unsigned int) D.25529; D.25531 = this + D.25530; *.LTHUNK0 (D.25531); ./cc1plus -fpreprocessed strstream.ii -quiet -dumpbase strstream.cc -mcpu=m32cm -auxbase-strip strstream.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wno-deprecated -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o strstream.s #0 verify_gimple_expr (expr=0xb6e79e80) at ../../gcc/gcc/tree-cfg.c:3653 #1 0x08557d3b in verify_gimple_modify_stmt (stmt=0xb6e7c7c4) at ../../gcc/gcc/tree-cfg.c:4012 #2 0x08557ed7 in verify_gimple_stmt (stmt=0xb6e7c7c4) at ../../gcc/gcc/tree-cfg.c:4045 #3 0x085588ec in verify_gimple_2 (stmts=0xb6e7c738) at ../../gcc/gcc/tree-cfg.c:4126 #4 0x08558943 in verify_gimple_1 (stmts=0xb6e7c738) at ../../gcc/gcc/tree-cfg.c:4143 #5 0x0840a079 in gimplify_body (body_p=0xb738da68, fndecl=0xb738da10, do_parms=1 '\001') at ../../gcc/gcc/gimplify.c:6536 #6 0x0840a5b5 in gimplify_function_tree (fndecl=0xb738da10) at ../../gcc/gcc/gimplify.c:6576 #7 0x08214aee in c_genericize (fndecl=0xb738da10) at ../../gcc/gcc/c-gimplify.c:105 #8 0x081cc445 in cp_genericize (fndecl=0xb738da10) at ../../gcc/gcc/cp/cp-gimplify.c:774 #9 0x0807e438 in finish_function (flags=0) at ../../gcc/gcc/cp/decl.c:11923 #10 0x081759e7 in use_thunk (thunk_fndecl=0xb738da10, emit_p=1 '\001') at ../../gcc/gcc/cp/method.c:525 #11 0x081829cd in emit_associated_thunks (fn=0xb738d850) at ../../gcc/gcc/cp/semantics.c:3157 #12 0x08762f00 in cgraph_expand_function (node=0xb743bc80) at ../../gcc/gcc/cgraphunit.c:1156 #13 0x08765c77 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1220 #14 0x0810a7fd in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3471 #15 0x08539e6b in toplev_main (argc=23, argv=0xbfad1944) at ../../gcc/gcc/toplev.c:971 #16 0x08225332 in main (argc=Cannot access memory at address 0x1 ) at ../../gcc/gcc/main.c:35
Re: Problem with Fix for PR 35163 ?
On Wed, Apr 9, 2008 at 8:10 AM, Pranav Bhandarkar [EMAIL PROTECTED] wrote: Btw, I have a fix. oh gr8. I just saw your post on the gcc-patches. Do you still want me to add this to PR35163 for the record ? Yes, IMHO it will be helpful if anyone is digging in these bugzillas. Thanks, Richard.
sizeof(array) with variable-length array parameter
Dear gcc users and developers,
This might be a stupid question, nevertheless...
I've been wondering for a long time, why the behaviour of
variable-length arrays w.r.t. the sizeof operator is different
for local/auto variables and for function arguments (in C99):
#include stdio.h
void foo(int s, int a[s]) {
printf(%u\n,sizeof a);
}
int main()
{
int s=10,a[s];
printf(%u\n,sizeof a);
foo(sizeof a/sizeof a[0],a);
}
The printf's produce very different results: the first one
returns 40 the other one returns 4, implying that the compiler
forgets that the size of the array is actually s, not the size
of the pointer argument. Is it so difficult to make sizeof a
return s in both cases?
The info page on gcc-4.3 does refer to variable-length arrays
in the context of the function declaration:
The length of an array is computed once when the storage is allocated
and is remembered for the scope of the array in case you access it
with `sizeof'.
This behaviour is fortunately consistent with all versions of gcc
that I actively use (2.95-4.3), so this might be a C99 feature that
is not implemented correctly...
Regards,
Pjotr Kourzanov
Re: improving auto increment expressions detection across basic blocks.
Hi Andrew,
I've been looking at doing this possibly in the store sinking pass and
have the following query as below.
On Mon, Apr 7, 2008 at 9:11 PM, Andrew Pinski [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 3:31 AM, Ramana Radhakrishnan [EMAIL PROTECTED]
wrote:
The basic case is as explained below.
for (i = 0; i 100; i ++)
{
if ()
{
a[i] = something;
}
else
a[i] = something else..
}
If it is this case, I think the store to a[i] should really sinked
below the if statement instead of doing anything fancy with
autoincrement.
Reg. the store sinking that you point out I've been looking at
tree-ssa-sink.c see if I can do something there .In sink_local it
appears as though the whole thing works by using dominator information
. The sinking process works by going block by block and attempting to
sink to a location which is dominated by this node.
Correct me if I am wrong but if you looked at the basic blocks in
which the stores are already contained, they would not be considered
for store sinking because they don't dominate anything really in the
CFG. So one wouldn't be able to do this in the current infrastructure
that we have in GCC. Is there any other place that one could look at ?
Cheers
Ramana
Thanks,
Andrew Pinski
--
Ramana Radhakrishnan
Re: sizeof(array) with variable-length array parameter
[EMAIL PROTECTED] wrote:
Dear gcc users and developers,
This might be a stupid question, nevertheless...
I've been wondering for a long time, why the behaviour of
variable-length arrays w.r.t. the sizeof operator is different
for local/auto variables and for function arguments (in C99):
#include stdio.h
void foo(int s, int a[s]) {
printf(%u\n,sizeof a);
}
int main()
{
int s=10,a[s];
printf(%u\n,sizeof a);
foo(sizeof a/sizeof a[0],a);
}
The printf's produce very different results: the first one
returns 40 the other one returns 4, implying that the compiler
forgets that the size of the array is actually s, not the size
of the pointer argument. Is it so difficult to make sizeof a
return s in both cases?
That's C for you, I'm afraid: arrays always decay to pointers to the
first element when passed as arguments. The size of a VLA is not passed.
Andrew.
Re: SSA Vs unSSA
You'd want to avoid translating from tuples back to nested trees. Instead when expanding from SSA form (ok, let's make that semi-SSA form that just keeps the UD chains but gets rid of PHI nodes (and maybe overlapping life ranges)) the expander can do expression combining by following the UD chain instead of relying on complex expressions re-constructed by TER. Sorry, i didn't understand the whole explanation. I think that you are talking about generation directly from SSA form, without translating back to GIMPLE, aren't you? Fran
Re: SSA Vs unSSA
Depends on what SSA form you want. A rewriting form is problematic because backends are allowed to modify the IL behind the back of the optimizers and can emit instructions that are difficult/impossible to represent in SSA form (parallel). I don't exactly know what rewriting SSA form means. I think that is a SSA form that could be updated along the several optimizations passes. From this previous explanation I deduce that SSA form goes on once the Middle-End layer has finished, and no translation to GIMPLE is performed, because target-dependent (or RTL) optimizations are applied to this SSA form. A non-rewriting form, however, is not hard to implement. We've discussed this a few weeks ago. At some point we will build a FUD-chain representation from the currently dense UD links in the DF code. What is the difference between rewriting and non-rewriting SSA form? From this I deduce that FUD-chain are used to translate from SSA to GIMPLE, isn't it? It's clear that translating from SSA form to GIMPLE is not trivial, and not always can be done. During the optimizations it is possible that new variables appear or that some statement are removed from Intermediate Representation, son unSSA wouldn't be performed. Fran
Re: more m32c brokenness
FYI: my h8/300h builds are failing with the same message, but with different types. Haven't investigated yet. What size is the internal 'sizetype'? 16 bits. Is there an integer type with the same width as the pointer type? No. The m32c doesn't have enough operators to have a pointer-sized sizetype (specifically, it needs an arbitrary-multiply op). There is a PSImode type, but no C type to correspond to it. Pointers are 24 bits because the address registers are physically 24 bits wide, and there are some math operators that operate on them directly (adding and shifting, mostly). But 24 bit math is incomplete, and 32 bit math is a LOT more expensive than 16 bit math. Basically the problems look like converting a pointer to an integer always either extends or truncates which is both prohibited in the GIMPLE IL (as the pointer doesn't have a sign we don't know whether to sign- or zero-extend it). In this case, though, we *are* doing signed arithmatic on it before converting. Plus, the code would work (for m32c) if there were no conversion at all - just leave it as a pointer type. Richard. [ gdb ] up #3 0x085588ec in verify_gimple_2 (stmts=0xb6e7c738) at ../../gcc/gcc/tree-cfg.c:4126 4126bool err2 = verify_gimple_stmt (stmt); [ gdb ] call debug_generic_expr (stmts) D.25526 = this-D.17063._vptr.basic_ostream; D.25527 = *D.25526; D.25528 = D.25527 + -12; D.25529 = *D.25528; D.25530 = (unsigned int) D.25529; D.25531 = this + D.25530; *.LTHUNK0 (D.25531);
Where is scheduling going wrong? - GCC-4.1.2
Hello all,
For a target that i porting in gcc 4.1.2 i am getting the following
assert failure :
internal compiler error: in schedule_region, at sched-rgn.c:2413
This is due to the following line
gcc_assert (sched_rgn_n_insns == rgn_n_insns);
I executed the program with -O2 option. When -fno-schedule-insn2 or
-fno-reorder-block is provided the program works fine.
The code that i am using for testing has 3 basic blocks. Block reorder
phase makes changes to produce the following as
the last basic block
;; Start of basic block 2, registers live: 7 [R7] 12 [R12]
(code_label 104 100 43 2 6 [1 uses])
(note 43 104 47 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(call_insn 47 43 105 2 (parallel [
(call (mem:HI (symbol_ref:HI (fun2) [flags 0x41]
function_decl 0xb7d33780 fun2) [0 S2 A16])
(const_int 0 [0x0]))
(use (reg:HI 7 R7 [28]))
]) 20 {*call_internal} (insn_list:REG_DEP_ANTI 41
(insn_list:REG_DEP_OUTPUT 37 (insn_list:REG_DEP_TRUE 17
(insn_list:REG_DEP_TRUE 16 (insn_list:REG_DEP_ANTI 39 (nil))
(nil)
(nil))
(jump_insn 105 47 106 2 (set (pc)
(label_ref 48)) -1 (nil)
(nil))
(barrier 106 105 107)
;; End of basic block 2, registers live:
7 [R7] 12 [R12]
This looks like reordering is proper. When schedule-insn2 is run for
the above region/block the no:of instructions in the region
(rgn_n_insns) is 3.
Initially call insn gets scheduled and then unconditional jump
instruction gets scheduled (hence sched_n_insns becomes 2). But since
the last scheduled instruction is a jump instruction scheduling stops
and comes out. Due to this the assertion fails. Looking at the code i
am not able to find out where
the problem might be. Can anyone help me?
Thanks for your time.
Regards,
Shafi.
Re: sizeof(array) with variable-length array parameter
On Wed, Apr 09, 2008 at 01:22:15PM +0100, Andrew Haley wrote:
[EMAIL PROTECTED] wrote:
Dear gcc users and developers,
This might be a stupid question, nevertheless...
I've been wondering for a long time, why the behaviour of
variable-length arrays w.r.t. the sizeof operator is different
for local/auto variables and for function arguments (in C99):
#include stdio.h
void foo(int s, int a[s]) {
printf(%u\n,sizeof a);
}
int main()
{
int s=10,a[s];
printf(%u\n,sizeof a);
foo(sizeof a/sizeof a[0],a);
}
The printf's produce very different results: the first one
returns 40 the other one returns 4, implying that the compiler
forgets that the size of the array is actually s, not the size
of the pointer argument. Is it so difficult to make sizeof a
return s in both cases?
That's C for you, I'm afraid: arrays always decay to pointers to the
first element when passed as arguments. The size of a VLA is not passed.
Well, it sort of is: it is actually passed as a parameter to the
function - look at the C99 defining a syntax for VLA parameters.
The fact the the compiler forgets about it could be compensated by
this...
What I would like to know, is why the standard (ISO/IEC 9899) does
explicitly require sizeof to return size of the pointer rather than
more obvious response? Is it backwards compatibility?
Is there any use in this behaviour besides making the life of
the compiler development team easy?
Surely, such an extension should be not too difficult to implement,
provided that the compiler can account for (potential) modifications
to the size parameter and require sizeof the return the value that
was actually passed to the function, which BTW, it already does,
since this behaviour is easily verified to work well for variable
VLAs.
In fact, strictly following C99 standard would force one that is
not familiar with the use of const on integer parameters to use
the s parameter to retrieve the size, which could lead to subtle
bugs if the parameter is modified on the way:
void foo(int s, int a[s]) {
s=20;
printf(%u\n,s);
}
Also, making sure that there are no out-of-bounds accesses
(mudflap) is simply impossible if the array size is not known...
Just curious...
Pjotr
Andrew.
Re: more m32c brokenness
On Wed, Apr 9, 2008 at 4:05 PM, DJ Delorie [EMAIL PROTECTED] wrote: FYI: my h8/300h builds are failing with the same message, but with different types. Haven't investigated yet. What size is the internal 'sizetype'? 16 bits. Is there an integer type with the same width as the pointer type? No. The m32c doesn't have enough operators to have a pointer-sized sizetype (specifically, it needs an arbitrary-multiply op). There is a PSImode type, but no C type to correspond to it. Pointers are 24 bits because the address registers are physically 24 bits wide, and there are some math operators that operate on them directly (adding and shifting, mostly). But 24 bit math is incomplete, and 32 bit math is a LOT more expensive than 16 bit math. I see. Basically the problems look like converting a pointer to an integer always either extends or truncates which is both prohibited in the GIMPLE IL (as the pointer doesn't have a sign we don't know whether to sign- or zero-extend it). In this case, though, we *are* doing signed arithmatic on it before converting. Plus, the code would work (for m32c) if there were no conversion at all - just leave it as a pointer type. Sorry, arithmetic on pointer-types is no longer possible. I guess we ran into this before (mismatch between sizetype and pointer type size), but as we have POINTER_PLUS_EXPR it should simply work. How does the source look like that we end up converting a pointer to an integer? Is the C intptr_t 32bits? Basically the GIMPLE IL requires an intermediate conversion to an integral type of the same width than the pointer type (it wants to leave the decision whether pointers sign- or zero-extend to the frontends, but at least not to every optimization pass looking at such conversions). I see the possibility of a target-hook here that converts a pointer to either a signed or unsigned (target choice) internal integral type. This hook would be called by the frontend for pointer-to-integer conversion. You may want to look into convert.c:convert_to_integer to hack this in there - just something like fold_convert (build_nonstandard_integer_type (TYPE_PRECISION (ptr_type), true/false), ptr); as first conversion if you enter with a pointer type argument. Richard.
Re: Problem with reloading in a new backend...
[Putting the gcc-list back in CC:, ]
Le mardi 08 avril 2008 à 18:24 -0400, DJ Delorie a écrit :
Do you have one insn for each pair of src/dest that movqi supports?
If so, this isn't the best way to do it - you should have one insn
with multiple constraint alternativess, not multiple insns.
[...]
reload deals with selecting among constraint
options, it doesn't usually have the choice about which pattern to
choose - the first that matches is used. If you have a list of
patterns that all match, only the first is available to reload. Plus,
reload gets confused when the predicates are used to choose among
otherwise identical patterns. So, it's best to have a more general
predicate (like general_operand) and use the constraints to tell
reload how to implement that insn in hardware.
Thanks to your suggestion, I changed my movqi pattern to look like:
(define_insn *movqi
[(set (match_operand:QI 0 nonimmediate_operand =r,y,y,m,r)
(match_operand:QI 1 general_operand r,n,s,r,m))]
{
switch (which_alternative) {
case 0: /* register to register */
return tfr %0,%1;
case 1: /* immediate to register */
output_asm_insn (ldih %0, hi(%1), operands);
output_asm_insn (ldil %0, lo(%1), operands);
return ;
case 2: /* immediate symbol to register */
output_asm_insn (ldih %0, hi(%c1), operands);
output_asm_insn (ldil %0, lo(%c1), operands);
return ;
case 3: /* register to memory */
if (GET_CODE (XEXP(operands[0], 0)) == REG) {
operands[0] = XEXP(operands[0], 0);
return st %1,(%0);
}
fatal_insn (Incorrect operand:, operands[0]);
case 4: /* memory to register */
if (GET_CODE (XEXP(operands[1], 0)) == REG) {
operands[1] = XEXP(operands[1], 0);
return ld %0,(%1);
}
fatal_insn (Incorrect operand:, operands[1]);
}
return ;
}
[(set_attr cc none)]
)
Does this look ok ? The 'fatal_insn' should not happen, because if I see
such a pattern in the define_expand movqi I force the use of a register:
(define_expand movqi
[(set (match_operand:QI 0 nonimmediate_operand )
(match_operand:QI 1 general_operand ))]
{
if (!reload_in_progress
!reload_completed) {
if (GET_CODE (operands[0]) == MEM
(GET_CODE (operands[1]) != REG)) {
operands[1] = force_reg (QImode, operands[1]);
}
else if (GET_CODE(operands[1]) == MEM
GET_CODE(XEXP(operands[1], 0)) == PLUS
GET_CODE(XEXP(XEXP(operands[1], 0), 0)) == REG
GET_CODE(XEXP(XEXP(operands[1], 0), 1)) ==
CONST_INT) {
/* indirect load */
XEXP(operands[1], 0) = force_reg (QImode, XEXP
(operands[1], 0));
}
else if (GET_CODE(operands[0]) == MEM
GET_CODE(XEXP(operands[0], 0)) == PLUS
GET_CODE(XEXP(XEXP(operands[0], 0), 0)) == REG
GET_CODE(XEXP(XEXP(operands[0], 0), 1)) ==
CONST_INT) {
/* indirect store */
XEXP(operands[0], 0) = force_reg (QImode, XEXP
(operands[0], 0));
}
}
}
)
This seems to work ok, but I still have issues at reload time, because
of the base register addressing mode: in the reload pass gcc generates
moves from/to the stack:
Reloads for insn # 3
Reload 0: reload_in (QI) = (reg/f:QI 31 r31)
EVEN_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (reg/f:QI 31 r31)
reload_reg_rtx: (reg:QI 0 r0)
Reload 1: reload_out (QI) = (mem/c:QI (plus:QI (reg/f:QI 31 r31)
(const_int -3
[0xfffd])) [10 S1 A16])
EVEN_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (reg:QI 109 [ u ])
But those moves are illegal because there is no offset allowed in the
base register addressing mode (see the definition of my
GO_IF_LEGITIMATE_ADDRESS() ),
so gcc crashes with 'unrecognizable insn'.
So what's the proper way to tell that indirect addressing is allowed,
but not with an offset ? Should I define an extra define_expand to deal
with those insns ?
Thanks again,
Stelian.
--
Stelian Pop [EMAIL PROTECTED]
Re: Problem with reloading in a new backend...
switch (which_alternative) {
case 0: /* register to register */
Better to just use the @ syntax that gcc offers, to provide multiple
patterns:
@
tfr %0,%1
ldih %0, hi(%1); ldil %0, lo(%1)
ldih %0, hi(%1); ldil %0, lo(%1)
st %1,(%0)
ld %0,(%1)
Everything else should have been sorted out by the constraints.
This seems to work ok, but I still have issues at reload time, because
of the base register addressing mode: in the reload pass gcc generates
moves from/to the stack:
You might need to define LEGITIMIZE_RELOAD_ADDRESS, or at least
LEGITIMIZE_ADDRESS. I don't know if reload has assumptions about such
offsets, but the m32c port has a limit on the offset range so it might
help you figure out your port.
Re: more m32c brokenness
Sigh, I cleaned out my local patches and now I'm tripping over this again: if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR) arg0 arg1 tt POINTER_TYPE_P (tt)) gcc_assert (TREE_CODE (arg0) == INTEGER_CST TREE_CODE (arg1) == INTEGER_CST); I had locally made that assert use || instead of as in one case it's passed a pointer type and an integer type for PLUS_EXPR. Also, convert_to_integer already knows to expand pointers to the maybe-next-size-bigger integer before converting them.[ gdb ] up [ gdb ] call debug_tree(arg0) indirect_ref 0xb710a440 type pointer_type 0xb7f23708 type pointer_type 0xb7f23640 __vtbl_ptr_type type function_type 0xb7f235dc unsigned PSI size integer_cst 0xb7e97498 constant invariant 32 unit size integer_cst 0xb7e97214 constant invariant 4 align 8 symtab 0 alias set 32 canonical type 0xb7f23640 pointer_to_this pointer_type 0xb7f23708 public unsigned PSI size integer_cst 0xb7e97498 32 unit size integer_cst 0xb7e97214 4 align 8 symtab 0 alias set 4 canonical type 0xb7f23708 pointer_to_this pointer_type 0xb79208fc arg 0 nop_expr 0xb710a420 type pointer_type 0xb79208fc type pointer_type 0xb7f23708 unsigned PSI size integer_cst 0xb7e97498 32 unit size integer_cst 0xb7e97214 4 align 8 symtab 0 alias set -1 canonical type 0xb79208fc readonly arg 0 non_lvalue_expr 0xb710a400 type pointer_type 0xb7cf10c8 readonly arg 0 parm_decl 0xb71b1b40 this [ gdb ] call debug_tree(arg1) integer_cst 0xb7917f34 type integer_type 0xb7e9f898 constant invariant -12 [ gdb ] where #0 fancy_abort (file=0x896d90c ../../gcc/gcc/tree.c, line=3107, function=0x896e57f build2_stat) at ../../gcc/gcc/diagnostic.c:654 #1 0x087204f7 in build2_stat (code=PLUS_EXPR, tt=0xb7f23708, arg0=0xb710a440, arg1=0xb7917f34) at ../../gcc/gcc/tree.c:3107 #2 0x08173836 in thunk_adjust (ptr=0xb710a400, this_adjusting=1 '\001', fixed_offset=0, virtual_offset=0xb7917f34) at ../../gcc/gcc/cp/method.c:241 #3 0x08175894 in use_thunk (thunk_fndecl=0xb7438a10, emit_p=1 '\001') at ../../gcc/gcc/cp/method.c:473 #4 0x0818636d in emit_associated_thunks (fn=0xb7438850) at ../../gcc/gcc/cp/semantics.c:3157 #5 0x08781830 in cgraph_expand_function (node=0xb744cc80) at ../../gcc/gcc/cgraphunit.c:1156 #6 0x087845a7 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1220 #7 0x0810a85d in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3471 #8 0x0853fc3b in toplev_main (argc=23, argv=0xbf8ecf54) at ../../gcc/gcc/toplev.c:971 #9 0x08228ce2 in main (argc=Cannot access memory at address 0x2d ) at ../../gcc/gcc/main.c:35
Re: Problem with reloading in a new backend...
Le mercredi 09 avril 2008 à 12:41 -0400, DJ Delorie a écrit :
switch (which_alternative) {
case 0: /* register to register */
Better to just use the @ syntax that gcc offers, to provide multiple
patterns:
@
tfr %0,%1
ldih %0, hi(%1); ldil %0, lo(%1)
ldih %0, hi(%1); ldil %0, lo(%1)
st %1,(%0)
ld %0,(%1)
Everything else should have been sorted out by the constraints.
Right.
This seems to work ok, but I still have issues at reload time, because
of the base register addressing mode: in the reload pass gcc generates
moves from/to the stack:
You might need to define LEGITIMIZE_RELOAD_ADDRESS, or at least
LEGITIMIZE_ADDRESS. I don't know if reload has assumptions about such
offsets, but the m32c port has a limit on the offset range so it might
help you figure out your port.
Ah, this looks exactly like what I needed, thanks!
I'll try this and come back afterwards.
--
Stelian Pop [EMAIL PROTECTED]
RE: US-CERT Vulnerability Note VU#162289
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: more m32c brokenness
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.
Re: Problem with reloading in a new backend...
Le mercredi 09 avril 2008 à 21:19 +0200, Stelian Pop a écrit : You might need to define LEGITIMIZE_RELOAD_ADDRESS, or at least LEGITIMIZE_ADDRESS. I don't know if reload has assumptions about such offsets, but the m32c port has a limit on the offset range so it might help you figure out your port. Ah, this looks exactly like what I needed, thanks! I'll try this and come back afterwards. Ok, I tried. Since displacements are not allowed in my addressing mode, I need to replace: (mem (plus (reg X) (const_int Y))) into (set (reg Z) (const_int Y)) (set (reg Z) (plus (reg Z) (reg X))) (mem (reg Z) This means I need to create a new pseodo register. This is allowed in LEGITIMIZE_ADDRESS but not in LEGITIMIZE_RELOAD_ADDRESS... Is there a way to do this ? Maybe I should reserve a special register for this usage (say r0). But maybe there is a better solution... Thanks, -- Stelian Pop [EMAIL PROTECTED]
Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
All the links your reference later in your email are actually dead links, from the documentation pre-Docbook. IMHO they should not be part of the libstdc++ online docs at all, but I don't know how to remove them. That should happen automatically, as far as I can tell, now that Paolo has adjusted a number of links. I'll keep an eye on it. No. I don't think I clearly explained this to you. For that, I am sorry. From what I can tell, the links to libstdc++ documentation on the gcc web site are generated from the gcc/libstdc++-v3/doc/html directory. This is fine, I guess. But the problem is that when this directory structure changed, none of the old files were deleted. Instead, we had the old and new documents live in one directory. This is a bug. On March 31, I moved all the old content into a director called dated. Or, at least all the stuff I could move: www/gcc/htdocs/onlinedocs/libstdc++/dated is the repository for all the old docs. In addition, ext/pb_assoc should be moved in to that as well, but I am lacking permissions to do this. -benjamin
Re: Problem with reloading in a new backend...
Maybe I should reserve a special register for this usage (say r0). That might be the only way, yes. 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).
gcc-4.2-20080409 is now available
Snapshot gcc-4.2-20080409 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080409/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 134151 You'll find: gcc-4.2-20080409.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080409.tar.bz2 C front end and core compiler gcc-ada-4.2-20080409.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080409.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080409.tar.bz2 C++ front end and runtime gcc-java-4.2-20080409.tar.bz2 Java front end and runtime gcc-objc-4.2-20080409.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080409.tar.bz2The GCC testsuite Diffs from 4.2-20080402 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Re: RFC: PowerPC floating point features
On Fri, 4 Apr 2008, Michael Eager wrote: Xilinx has a PowerPC 405 processor with an attached single precision floating point processor. I have a patch which supports this FP unit, but want to clean it up a bit before submitting it. What do you propose as the function call and return ABI when this is in use? At present we (32-bit GNU/Linux and EABI) have a hard-float ABI (TARGET_HARD_FLOAT TARGET_FPRS), which relies on 64-bit FPRs to be able to pass double (so isn't usable if this processor only has 32-bit FPRs), and a soft-float ABI, also used on E500, passing floating point types in GPRs (32 bits of each GPR, not using the E500 high parts). Are you going to use the soft-float ABI and take the performance cost of doing so, or do you propose a hybrid ABI passing float in FPRs and double in GPRs? If you propose the latter then you should work with the Power.org ABI working group on defining the ABI properly. (Whatever you do, you may wish to consider how to define flags relating to the ABI separately from those relating to code generation.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: RFC: PowerPC floating point features
Joseph S. Myers wrote: On Fri, 4 Apr 2008, Michael Eager wrote: Xilinx has a PowerPC 405 processor with an attached single precision floating point processor. I have a patch which supports this FP unit, but want to clean it up a bit before submitting it. What do you propose as the function call and return ABI when this is in use? At present we (32-bit GNU/Linux and EABI) have a hard-float ABI (TARGET_HARD_FLOAT TARGET_FPRS), which relies on 64-bit FPRs to be able to pass double (so isn't usable if this processor only has 32-bit FPRs), and a soft-float ABI, also used on E500, passing floating point types in GPRs (32 bits of each GPR, not using the E500 high parts). Are you going to use the soft-float ABI and take the performance cost of doing so, or do you propose a hybrid ABI passing float in FPRs and double in GPRs? If you propose the latter then you should work with the Power.org ABI working group on defining the ABI properly. It's a hybrid ABI. Floats are passed in single precision FPRs, doubles are passed in pairs of GPRs. I'll look into what power.org is doing. Do you have a contact? (Whatever you do, you may wish to consider how to define flags relating to the ABI separately from those relating to code generation.) I look into this. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
TREE_ADDRESSABLE flag
I came across the following problem when trying to instrument the program. If I take the address of trees using build_fold_addr_expr at O2 the compiled programs crash (segmentation fault) at runtime. They run OK at O0. In this particular case I only took the addresses of var_decl and parm_decl nodes. What optimization could I be interfering with? In fact I did not perform instrumentation for I noticed that the moment build_fold_addr_expr is called and it set the TREE_ADDRESSABLE flag the program would crash. thanks. -- dasarath
Re: RFC: named address space support
Hi Mark I agree. Much to my dismay, the C and C++ committees don't seem to be willing to work together to make sure that C remains a subset of C++. I'm afraid my patch doesn't address that. :-) Ben, to answer your original question, I don't think that lack of nested address spaces is a fatal flaw, as long as the implementation otherwise meets the spec, and as long as the implementation doesn't somehow make it harder to add that. Good, I was hoping that would be the general opinion. However, I'd like to know how final this proposal is, and how likely it is to make the WG14 WP. I don't really know the answer to that. I will try and find out. Perhaps Chao-ying Fu (cc'ed) who implemented the fixed point arithmetic portion of the proposal knows more? As always, I'm concerned about putting things into GCC and then finding out that we have to change them in ways that are not backwards compatible. Absolutely understood! Cheers, Ben
omp workshare (PR35423) beginner questions
Hello,
I am a beginner interested in learning gcc internals and contributing
to the community.
I have started implementing PR35423 - omp workshare in the fortran
front-end. I have some questions - any guidance and suggestions are
welcome:
- For scalar assignments, wrapping them in OMP_SINGLE clause.
- Array/subarray assignments: For assignments handled by the
scalarizer, I now create an OMP_FOR loop instead of a LOOP_EXPR for
the outermost scalarized loop. This achieves worksharing at the
outermost loop level.
Some array assignments are handled by functions (e.g.
gfc_build_memcpy_call generates calls to memcpy). For these, I believe
we need to divide the arrays into chunks and have each thread call the
builtin function on its own chunk. E.g. If we have the following call
in a parallel workshare construct:
memcpy(dst, src, len)
I generate this pseudocode:
{
numthreads = omp_get_numthreads();
chunksize = len / numthreads;
chunksize = chunksize + ( len != chunksize*numthreads)
}
#omp for
for (i = 0; i numthreads; i++) {
mysrc = src + i*chunksize;
mydst = dst + i*chunksize;
mylen = min(chunksize, len - (i*chunksize));
memcpy(mydst, mysrc, mylen);
}
If you have a suggestion to implement this in a simpler way, let me know.
The above code executes parallel in every thread. Alternatively, the
first block above can be wrapped in omp_single, but the numthreads
chunksize variables should then be
declared shared instead of private. All the variables above
are private by default, since they are declared in a parallel
construct.
How can I set the scoping for a specific variable in a given
omp for construct? Is the following correct to make a variable shared:
tmp = build_omp_clause(OMP_CLAUSE_SHARED);
OMP_CLAUSE_DECL(tmp) = variable;
omp_clauses = gfc_tran_add_clause(tmp, );
- I still need to do worksharing for array reduction operators (e.g.
SUM,ALL, MAXLOC etc). For these, I think a combination of OMP_FOR/OMP_SINGLE or
OMP_REDUCTION is needed. I will also try to work on WHERE and
FORALL statements.
I am also interested in gomp3 implementation and performance issues.
If there are not-worked-on issues suitable for newbies, please share
or update http://gcc.gnu.org/wiki/openmp. Can someone elaborate on the
Fine tune the auto scheduling feature for parallel loops issue?
Also, in the beginner projects
(http://gcc.gnu.org/projects/beginner.html) , under optimizer
improvements, it would be good to know which of these projects are
not stale/obsolete. Middle-end or x86/x86_64 backend issues for
beginners are of interest.
thanks,
- Vasilis
[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory
--- Comment #3 from charlet at gcc dot gnu dot org 2008-04-09 06:45 --- missing debug info is never really major, since there are always work arounds (like print statements). Note that there is close to zero chance that someone will look into your .bz2 file, let alone your README. Instructions (and test case simplification) should be part of the submission of a PR if you want someone to look at it. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880
[Bug libgomp/35881] New: OMP atypical results for omp_get_max_threads
The following test program returns 1 for omp_get_max_threads in a parallel region. This is different from what I get with three other compilers, and hence somewhat unexpected. Is this correct, and if so, should it be the default? gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_4_3_0_release/gcc-4.3.0/configure --prefix=/ext/software/64/gfortran-suite/gcc-4.3.0 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 (GCC) SUBROUTINE TEST() IMPLICIT NONE INTEGER :: ithread,nthread,mthread !$ INTEGER :: omp_get_thread_num, omp_get_max_threads, omp_get_num_threads ithread=0 nthread=1 mthread=1 !$ nthread=omp_get_max_threads() write(6,*) ithread,nthread,mthread !$OMP PARALLEL PRIVATE(ithread,nthread,mthread) !$ nthread=omp_get_max_threads() !$ mthread=omp_get_num_threads() !$ ithread=omp_get_thread_num() !$OMP CRITICAL write(6,*) ithread,nthread,mthread !$OMP END CRITICAL !$OMP END PARALLEL END SUBROUTINE TEST CALL TEST() END IBM: [EMAIL PROTECTED]:~ xlf90_r -qsuffix=f=f90 -O3 -qsmp=omp test.f90 ** test === End of Compilation 1 === ** _main === End of Compilation 2 === 1501-510 Compilation successful for file test.f90. [EMAIL PROTECTED]:~ ./a.out 0 4 1 0 4 4 1 4 4 3 4 4 2 4 4 [EMAIL PROTECTED]:/data03/vondele/openmp pgf90 -openmp test.f90 [EMAIL PROTECTED]:/data03/vondele/openmp ./a.out 0 4 1 0 4 4 1 4 4 2 4 4 3 4 4 [EMAIL PROTECTED]:/data03/vondele/openmp ifort -O0 -openmp test.f90 test.f90(13): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED. [EMAIL PROTECTED]:/data03/vondele/openmp ./a.out 0 4 1 0 4 4 1 4 4 2 4 4 3 4 4 [EMAIL PROTECTED]:/data03/vondele/openmp gfortran -O0 -fopenmp test.f90 [EMAIL PROTECTED]:/data03/vondele/openmp ./a.out 0 4 1 0 1 4 1 1 4 2 1 4 3 1 4 -- Summary: OMP atypical results for omp_get_max_threads Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35881
[Bug fortran/35882] New: Miscounted continuation lines when interspersed with data
gfortran seems to misreport a warning about exceeding the number of continuation lines limit (39 lines of continuation) in certain cases when compiled with -pedantic. We found the bug when using a very long write statement, with alternating continuation lines of string literals and data. The bug does not appear if only string literals are used. The bug results in reporting the wrong line as the first invalid continuation line (if there are indeed more than 39) or that there are too many (in the case where there are 39 or fewer). Thanks, Jonathan. Full test case: [EMAIL PROTECTED] ~/bugs/gfortran-4.3/continuation $ gfortran-4.3 -pedantic -o test test.f90 test.f90:23: Line 15, 1 Warning: Limit of 39 continuations exceeded in statement at (1) [EMAIL PROTECTED] ~/bugs/gfortran-4.3/continuation $ gfortran-4.3 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --program-suffix=-4.3 Thread model: posix gcc version 4.3.0 (GCC) [EMAIL PROTECTED] ~/bugs/gfortran-4.3/continuation $ cat test.f90 program test_mod implicit none integer, dimension(50) :: array array = 1 print (a, i8), Line 1, array(2), Line 3, array(4), Line 5, array(6), Line 7, array(8), Line 9, array(10), Line 11, array(12), Line 13, array(14), Line 15, array(16), Line 17, array(18), Line 19, array(20), Line 21, array(22), Line 23, array(24), Line 25, array(26), Line 27, array(28), Line 29, array(30), Line 31, array(32), Line 33, array(34), Line 35, array(36), Line 37, array(38), Line 39, array(40), Line 41, array(42), Line 43 end program -- Summary: Miscounted continuation lines when interspersed with data Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: J dot Hogg at rl dot ac dot uk 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=35882
[Bug libgomp/35881] OMP atypical results for omp_get_max_threads
--- Comment #1 from jv244 at cam dot ac dot uk 2008-04-09 08:07 --- reading a bit more, this seems a real bug. Can this be fixed for 4.3, pretty please ? -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords||wrong-code Summary|OMP atypical results for|OMP atypical results for |omp_get_max_threads |omp_get_max_threads http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35881
[Bug other/35858] time/memory hog for large c++ source.
--- Comment #8 from rguenther at suse dot de 2008-04-09 08:08 --- Subject: Re: time/memory hog for large c++ source. On Tue, 8 Apr 2008, pluto at agmk dot net wrote: --- Comment #7 from pluto at agmk dot net 2008-04-08 16:50 --- (In reply to comment #6) We'll not be able to fix this for 4.3 (the regression is caused by a correctness fix), but 4.4 will have this param setting as default. Can i safely set this parameter to zero for vendor gcc package? Does the non-zero value fix some bugs or sth? In principle you can set it to zero, but you will lose optimization opportunities in the areas of PRE/FRE, loop invariant and store motion (to name the probably most important ones). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
[Bug fortran/35882] Miscounted continuation lines when interspersed with data
--- Comment #2 from burnus at gcc dot gnu dot org 2008-04-09 09:19 ---
We found the bug when using a very long write statement, with alternating
continuation lines of string literals and data. The bug does not appear if
only string literals are used.
I forget to say thank you for the bug report.
The problem that the number miscounts for comment/empty lines should be fixed
by the following patch (untested), but I did not see the actual problem.
... I think it is caused by repeatedly parsing the same line; one could try to
fix it as follows:
Index: scanner.c
===
--- scanner.c (revision 134131)
+++ scanner.c (working copy)
@@ -811,18 +811,19 @@ restart:
/* We've got a continuation line. If we are on the very next line after
the last continuation, increment the continuation line count and
check whether the limit has been exceeded. */
- if (gfc_linebuf_linenum (gfc_current_locus.lb) == continue_line + 1)
+ if (gfc_linebuf_linenum (gfc_current_locus.lb) continue_line)
{
if (++continue_count == gfc_option.max_continue_free)
{
if (gfc_notification_std (GFC_STD_GNU) || pedantic)
gfc_warning (Limit of %d continuations exceeded in
statement at %C, gfc_option.max_continue_free);
}
+
+ continue_line = gfc_linebuf_linenum (gfc_current_locus.lb);
}
- continue_line = gfc_linebuf_linenum (gfc_current_locus.lb);
/* Now find where it continues. First eat any comment lines. */
openmp_cond_flag = skip_free_comments ();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35882
[Bug fortran/35882] Miscounted continuation lines when interspersed with data
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-09 09:05 --- Confirm. The problem is not the settings, but that the counting goes wrong. This can also be seen if one adds comment or empty lines in between. One would expect that this should not affect the line count (i.e. error still in line 15) or that the number decreases, however, it increases. There is also another bug: The default value for -std=gnu/legacy should be 255 (Fortran 2003) and not 39 (Fortran 95). Currently, -std=gnu -pedantic warns for 39 continuation lines but with -std=f2003 -pedantic only for 255 continuation lines! Note: For fixed form source it actually works, even if one adds empty lines/comment lines. The additional bug is fixed by the following patch. The reported bug needs some studying of scanner.c Index: options.c === --- options.c (revision 134131) +++ options.c (working copy) @@ -61,2 +61,2 @@ gfc_init_options (unsigned int argc ATTR - gfc_option.max_continue_fixed = 19; - gfc_option.max_continue_free = 39; + gfc_option.max_continue_fixed = 255; + gfc_option.max_continue_free = 255; @@ -736,0 +737,2 @@ gfc_handle_option (size_t scode, const c + gfc_option.max_continue_fixed = 19; + gfc_option.max_continue_free = 39; @@ -745,2 +746,0 @@ gfc_handle_option (size_t scode, const c - gfc_option.max_continue_fixed = 255; - gfc_option.max_continue_free = 255; @@ -756,2 +755,0 @@ gfc_handle_option (size_t scode, const c - gfc_option.max_continue_fixed = 255; - gfc_option.max_continue_free = 255; -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2008-04-09 09:05:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35882
[Bug c++/35883] Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067
--- Comment #3 from bachlipp at web dot de 2008-04-09 10:05 --- Created an attachment (id=15454) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15454action=view) Preprocessed source file, third chunk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35883
[Bug tree-optimization/35821] Internal compiler error: segmentation fault
--- Comment #8 from irar at gcc dot gnu dot org 2008-04-09 10:55 --- Subject: Bug 35821 Author: irar Date: Wed Apr 9 10:55:11 2008 New Revision: 134136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134136 Log: PR tree-optimization/35821 * tree-vect-transform.c (vect_create_data_ref_ptr): Add check that NEW_STMT_LIST is not NULL. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/pr35821-altivec.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/pr35821-spu.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35821
[Bug libgomp/35881] OMP wrong results for omp_get_max_threads
--- Comment #2 from jv244 at cam dot ac dot uk 2008-04-09 10:58 --- also confirmed for trunk -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail|4.2.3 4.3.0 |4.2.3 4.3.0 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35881
[Bug c++/35884] defining __need_size_t before including cstddef causes error
--- Comment #1 from pcarlini at suse dot de 2008-04-09 11:22 --- Names starting with __ and _ (see 17.4.3.1 for details) are reserved. That's exactly the reason why the library uses everywhere and only such names (why, otherwise?) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35884
[Bug c/35885] New: unsinged long long and while loop evaluation regression?
The following program:
#include stdio.h
int main(int argc, char **argv) {
unsigned inttestu32a = 0x506f85f;
unsigned long long testu64a = 0x9afa246709018f48ULL;
printf(before: testu64a = %08x%08x, testu32a = %08x\n, (unsigned
int)( testu64a 32 ), (unsigned int)( testu64a 0x ), testu32a );
while ((unsigned long long)testu32a * (unsigned long long)0x
testu64a)
testu64a /= 2;
printf(after: testu64a = %08x%08x, testu32a = %08x\n, (unsigned int)(
testu64a 32 ), (unsigned int)( testu64a 0x ), testu32a );
return 0;
}
When compiled under freebsd 6 using gcc -o test test.c gives different
results when using gcc 3.4.4 or gcc 4.2.4:
Using 3.4.4:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 04d7d12338480c7a, testu32a = 0506f85f
Using 4.2.4:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 9afa246709018f48, testu32a = 0506f85f
The behavior of 4.2.4 has also been seen on a linux gentoo machine running gcc
4.1.2, a 64bit xp machine running gcc 4.2.1, and a regular xp machine running
gcc 4.2.1.
--
Summary: unsinged long long and while loop evaluation regression?
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilbert at jdg dot info
GCC build triplet: several
GCC host triplet: several
GCC target triplet: several
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35885
[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-09 10:32 --- This fails actually since: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132282 AKA PR34824. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773
[Bug c++/35883] Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067
--- Comment #1 from bachlipp at web dot de 2008-04-09 10:04 --- Created an attachment (id=15452) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15452action=view) Preprocessed source file, first chunk Generated from original log4cplus-1.0.2 distribution, configured using just ./configure, copying and modifying the g++ call originating from the call to make like this: cd src g++ -DHAVE_CONFIG_H -I. -I. -I../include/log4cplus -I../include -Wall -D_REENTRANT -g -O2 -c appender.cxx -DDLL_EXPORT -DPIC -save-temps -o .libs/appender.o Then splitted using split --bytes=70 appender.li -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35883
[Bug c++/35884] New: defining __need_size_t before including cstddef causes error
When you define __need_size_t before including cstddef it only pulls in
size_t, but the cstddef header expects ptrdiff_t there too and fails.
sample code:
--
#define __need_size_t
#include cstddef
main() {}
--
error message produced by g++:
$ g++ main.cpp
In file included from main.cpp:2:
/usr/include/c++/4.3/cstddef:55: error: ::ptrdiff_t has not been declared
--
Summary: defining __need_size_t before including cstddef causes
error
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stdin at stdin dot me dot uk
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35884
[Bug c++/35883] Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067
--- Comment #2 from bachlipp at web dot de 2008-04-09 10:05 --- Created an attachment (id=15453) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15453action=view) Preprocessed source file, second chunk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35883
[Bug c++/35883] New: Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067
I tried to compile log4cplus-1.0.2 with the latest stable GCC distributed with MinGW (gcc-*-3.4.5-20060117-2). This failed. So I compiled GCC 3.4.6 myself: export PATH=/mingw/bin:$PATH export GCC_EXEC_PREFIX=/mingw/lib/gcc/ cd .. mkdir mingw32 cd mingw32 mkdir /usr/include ../gcc-3.4.6/configure --with-gcc --with-gnu-ld --with-gnu-as \ --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads \ --disable-nls --enable-languages=c,c++,f77,ada,objc,java \ --disable-win32-registry --disable-shared --enable-sjlj-exceptions \ --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm \ --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization \ --enable-libstdcxx-debug --enable-languages=c,c++ make BOOT_CFLAGS=-O2 -fomit-frame-pointer -D__USE_MINGW_ACCESS \ BOOT_CXXFLAGS=-mthreads -fno-omit-frame-pointer -O2 \ BOOT_LDFLAGS=-s \ bootstrap make install Now I have $ g++ --version g++.exe (GCC) 3.4.6 [...] $ uname -a MINGW32_NT-5.1 [hostname] 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown Updating the compiler didn't solve the problem. It still says: appender.cxx:245: warning: function 'virtual log4cplus::tstring log4cplus::Appender::getName()' is defined after prior declaration as dllimport: attribute ignored appender.cxx:253: warning: function 'virtual void log4cplus::Appender::setName(const log4cplus::tstring)' is defined after prior declaration as dllimport: attribute ignored appender.cxx:268: warning: function 'virtual void log4cplus::Appender::setErrorHandler(std::auto_ptrlog4cplus::ErrorHandler)' is defined after prior declaration as dllimport: attribute ignored appender.cxx:260: warning: function 'virtual log4cplus::ErrorHandler* log4cplus::Appender::getErrorHandler()' is defined after prior declaration as dllimport: attribute ignored appender.cxx:284: warning: function 'virtual void log4cplus::Appender::setLayout(std::auto_ptrlog4cplus::Layout)' is defined after prior declaration as dllimport: attribute ignored appender.cxx:294: warning: function 'virtual log4cplus::Layout* log4cplus::Appender::getLayout()' is defined after prior declaration as dllimport: attribute ignored appender.cxx:95: warning: function 'virtual void log4cplus::OnlyOnceErrorHandler::error(const log4cplus::tstring)' is defined after prior declaration as dllimport: attribute ignored appender.cxx:84: warning: function 'virtual log4cplus::ErrorHandler::~ErrorHandler()' is defined after prior declaration as dllimport: attribute ignored appender.cxx:84: warning: function 'virtual log4cplus::ErrorHandler::~ErrorHandler()' is defined after prior declaration as dllimport: attribute ignored appender.cxx: In destructor `log4cplus::ErrorHandler::~ErrorHandler()': appender.cxx:85: internal compiler error: in rest_of_handle_final, at toplev.c:2067 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The command line used was: g++ -DHAVE_CONFIG_H -I. -I. -I../include/log4cplus -I../include -Wall -D_REENTRANT -g -O2 -c appender.ii -DDLL_EXPORT -DPIC -o .libs/appender.o This is similar to what a simple ./configure yielded. Please find the lengthy preprocessed source attached. -- Summary: Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067 Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bachlipp at web dot de GCC build triplet: *-*-* GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35883
[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90
--- Comment #5 from burnus at gcc dot gnu dot org 2008-04-09 11:46 --- I see it on x86-64 Linux clearly enough and with -m32 and -m64. I think Paul removed a check that we have to put back in. Whereas I do not see it, neither with -m32 nor -m64 on x86-64-linux (openSUSE Factory); not even using valgrind. This is with gfortran 4.4.0 20080409 (experimental) [trunk revision 134131] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
[Bug c++/35883] Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-09 13:01 --- Sorry, but the oldest GCC version still maintained is GCC 4.1.2 though I suggest to at least try GCC 4.2.x which will even get further updates. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35883
[Bug c/35885] unsigned long long and while loop evaluation regression?
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-09 13:05 --- This works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35885
[Bug ada/35886] New: Bad location of error message
GNAT switches the location of the full type and the incomplete type when a tagged type is completed with a non-tagged record: % gcc -gnatv -c p.ads GNAT 4.4.0 20080409 (experimental) Copyright 1992-2008, Free Software Foundation, Inc. Compiling: p.ads (source file time stamp: 2008-04-09 13:15:07) 3.type T is tagged; | full declaration of type T defined at line 4 must be tagged 6 lines: 1 error -- package P is type T is tagged; type T is null record; end P; -- Summary: Bad location of error message Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ada AssignedTo: sam at gcc dot gnu dot org ReportedBy: sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35886
[Bug ada/35886] Bad location of error message
-- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-09 13:27:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35886
[Bug libgomp/35881] OMP wrong results for omp_get_max_threads
--- Comment #3 from jv244 at cam dot ac dot uk 2008-04-09 13:31 --- I decided to ask, and maybe it is correct anyway, even though I have not fully followed the bit on 'nthreads-var' http://www.openmp.org/forum/viewtopic.php?f=3t=100 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35881
[Bug ada/35792] Illegal program not detected, RM 3.10.1(4/2)
--- Comment #1 from sam at gcc dot gnu dot org 2008-04-09 13:38 --- Confirmed on GCC 4.4.0 20080409. -- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-09 13:38:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35792
[Bug c++/35838] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others
--- Comment #2 from danglin at gcc dot gnu dot org 2008-04-09 14:13 --- This was introduced in revision 133452. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35838
[Bug ada/28305] GNAT bug when inlining instance of a generic subprogram
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-09 14:22 --- Subject: Bug 28305 Author: sam Date: Wed Apr 9 14:21:18 2008 New Revision: 134142 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134142 Log: gcc/ada/ PR ada/28305 * sem_ch6.adb (Build_Body_To_Inline): Do not save and restore environment if generic instance is a top-level one. gcc/testsuite/ PR ada/28305 * gnat.dg/specs/fe_inlining.ads, gnat.dg/specs/fe_inlining_helper.ads, gnat.dg/specs/fe_inlining_helper.adb: New test. Added: trunk/gcc/testsuite/gnat.dg/specs/fe_inlining.ads trunk/gcc/testsuite/gnat.dg/specs/fe_inlining_helper.adb trunk/gcc/testsuite/gnat.dg/specs/fe_inlining_helper.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch6.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28305
[Bug ada/28305] GNAT bug when inlining instance of a generic subprogram
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-09 14:22 --- Fixed in SVN trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28305
[Bug libstdc++/35887] New: stl parallel includes installed for --disable-libgomp
with --disable-libgomp buildsystem omits omp.h installation but installs libstdc++/parallel stuff which depends on it. this won't work. -- Summary: stl parallel includes installed for --disable-libgomp Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug c++/35734] [4.3/4.4 regression] ICE with copy constructor in derived class
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-09 14:25 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35734
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #12 from jakub at gcc dot gnu dot org 2008-04-09 14:32 ---
Created an attachment (id=15455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455action=view)
gcc43-pr35634.patch
Here is the updated FE only patch. One change is that it avoids
P{RE,OST}{IN,DE}CREMENT_EXPR only for the promoting types, and has some
(admittedly very ugly) OpenMP parsing changes to counter that. Unfortunately
unlike #pragma omp for increment, #pragma omp atomic can have some_lvalue++
, not necessarily a variable_name++, so I have no idea how to handle that.
On x86_64 with this patch I get 3 omp failures (2 in libgomp atomic-10.c, one
in gcc/testsuite atomic-1.c) and:
FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect vectorized 1
loops 2
so (depending on where the other patch was tested) doing this in the FE doesn't
help much or at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug libstdc++/35597] libstdc++ -ffunction-sections -fdata-sections disabled on AIX
--- Comment #5 from dje at gcc dot gnu dot org 2008-04-09 14:41 --- Subject: Bug 35597 Author: dje Date: Wed Apr 9 14:41:07 2008 New Revision: 134143 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134143 Log: PR libstdc++/35597 * toplev.c (process_options): Remove -ffunction-sections debugging warning. Modified: trunk/gcc/ChangeLog trunk/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35597
[Bug ada/35888] New: ICE: converting a concrete type into a classwide interface
The following package spec package B is type I is Interface; type C is new I with null record; function M return C; X : I'Class := I'Class (M); end B; triggers an infinite recursion in GNAT: +===GNAT BUG DETECTED==+ | 4.4.0 20080409 (experimental) (i686-pc-linux-gnu) Storage_Error stack overflow (or erroneous memory access)| | Error detected at b.ads:5:20 | -- Summary: ICE: converting a concrete type into a classwide interface Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sam at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35888
[Bug libgomp/29986] testsuite failures
--- Comment #4 from scovich at gmail dot com 2008-04-09 15:18 ---
If it's any help, adding some inline asm to the file makes the Sun toolchain
croak on my machine.
SunOS 5.10 Generic_118833-23 sun4v sparc SUNW,Sun-Fire-T200
Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
Solaris Link Editors: 5.10-1.482
// begin tls-bug.c
void membar_producer() { asm volatile(membar #StoreStore); }
static __thread bool val;
int main() { return val; }
// end tls-bug.c
This bug seems to show up in arbitrary ways for each of the three compilers on
my machine:
$ cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
$ ~/apps/gcc/4.3/bin/gcc-4.3 -v
Using built-in specs.
Target: sparc64-sun-solaris2.10
Configured with: ../configure --prefix=/export/home/ryanjohn/apps/gcc/4.3
--build=sparc64-sun-solaris2.10 --program-suffix=-4.3
--with-mpfr=/export/home/ryanjohn/apps --with-gmp=/export/home/ryanjohn/apps
--disable-multilib --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
Thread model: posix
gcc version 4.3.0 (GCC)
Note that all three use the same copy of ld
$ cc tls-bug.c
$ cc -g tls-bug.c
$ CC tls-bug.c
ld: fatal: relocation error: R_SPARC_TLS_GD_HI22: file tls-bug.o:
symbolunknown: bad symbol type SECT: symbol type must be TLS
$ CC -g tls-bug.c
$ gcc -m64 tls-bug.c
$ gcc -m64 -g tls-bug.c
ld: fatal: relocation error: R_SPARC_TLS_DTPOFF64: file /var/tmp//ccuJHWqp.o:
symbol done: offset 0x7d901c33 is non-aligned
collect2: ld returned 1 exit status
$ gcc-4.3 tls-bug.c
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file /var/tmp//ccUeK1AZ.o:
symbol unknown: bad symbol type SECT: symbol type must be TLS
collect2: ld returned 1 exit status
$ gcc-4.3 tls-bug.c -g
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file /var/tmp//cceRP4ZP.o:
symbol unknown: bad symbol type SECT: symbol type must be TLS
collect2: ld returned 1 exit status
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory
--- Comment #4 from knoxj at att dot net 2008-04-09 15:19 --- Print statements work if you know what you want to look at. The application is an aircraft simulation by stimulating avionics black boxes. We use a debugger to examine state information while the simulation is running to try to determine problem causes. I spent 3 days condensing hundreds of thousands of source lines to the test case I submitted. I tried to provide a short test case to demonstrate the problem. I ended up with 14 files consisting of 2226 actual source lines. I thought I read in the submission guidelines that an attachment was acceptable in a case like this. If I should submit the file contents as a large file, please point me to a sample so I know how to format the various individual file contents. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880
[Bug c++/35889] spu_check_builtin_parm function fails on templates.
--- Comment #1 from rbertran at ac dot upc dot edu 2008-04-09 15:20 --- Created an attachment (id=15456) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15456action=view) Temp file generated when -save-temps flag is set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35889
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #13 from rguenther at suse dot de 2008-04-09 15:26 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] operand of
pre-/postin-/decrement not promoted
On Wed, 9 Apr 2008, jakub at gcc dot gnu dot org wrote:
--- Comment #12 from jakub at gcc dot gnu dot org 2008-04-09 14:32
---
Created an attachment (id=15455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455action=view)
gcc43-pr35634.patch
Here is the updated FE only patch. One change is that it avoids
P{RE,OST}{IN,DE}CREMENT_EXPR only for the promoting types, and has some
(admittedly very ugly) OpenMP parsing changes to counter that. Unfortunately
unlike #pragma omp for increment, #pragma omp atomic can have some_lvalue++
, not necessarily a variable_name++, so I have no idea how to handle that.
On x86_64 with this patch I get 3 omp failures (2 in libgomp atomic-10.c, one
in gcc/testsuite atomic-1.c) and:
FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops
1
FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect vectorized 1
loops 2
so (depending on where the other patch was tested) doing this in the FE
doesn't
help much or at all.
Thanks!
I will try doing the P{RE,OST}{IN,DE}CREMENT_EXPR semantic change and
handling it in the gimplifier. Just because I am curious how much
I break the frontends...
After the summit paper deadline is over ;)
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c++/35889] spu_check_builtin_parm function fails on templates.
--- Comment #3 from rbertran at ac dot upc dot edu 2008-04-09 15:25 --- Created an attachment (id=15457) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15457action=view) Temp file generated when -save-temps flag is set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35889
[Bug c++/35889] New: spu_check_builtin_parm function fails on templates.
Hello,
I'm using gcc4.3.0 for compiling cell binaries on a x86 platform.
I've some benchmarks that use c++ templates like:
template typename T inline
T rot_veci( T v, int n )
{
return (T) si_rotqbyi( (vector signed char)v, n );
}
When compiling, I get the following error:
error: si_rotqbyi expects an integer literal in the range [-64, 127].
So, I suppose that gcc is not able to know the value of the 'n' parameter.
Then, the builtins intrinsics checks for the literal range and raise the
error.
I've been googling and I found references [1][2] about this problem (or
similar problem). I guess that the problem comes from the
spu_check_builtin_parm function in gcc/config/spu/spu.c . I have reported
the problem to IBM cell forums, too.
Thanks in advance,
Salut!
[1] http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00130.html
[2] http://gcc.gnu.org/ml/gcc-patches/2006-12/txt0.txt
--
Summary: spu_check_builtin_parm function fails on templates.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbertran at ac dot upc dot edu
GCC build triplet: x86-linux-gnu
GCC host triplet: x86-linux-gnu
GCC target triplet: spu-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35889
[Bug c++/35889] spu_check_builtin_parm function fails on templates.
--- Comment #2 from rbertran at ac dot upc dot edu 2008-04-09 15:24 --- Command executed: spu-g++ -ffreestanding -Wall -ffast-math -fno-rtti -fno-exceptions --function-sections --data-sections -fsigned-char -I -I../.. -I../../include -I./org -I. `pkg-config --cflags opencv` -I/usr/spu/include -I../../cellsdk/spu/include -c cvHaarDetectObjects_spu.cpp -o obj/cvHaarDetectObjects_spu.ospu -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35889
[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory
--- Comment #5 from charlet at adacore dot com 2008-04-09 15:25 --- Subject: Re: GNAT (GCC) Ada does not generate symbolic debug for shared memory The application is an aircraft simulation by stimulating avionics black boxes. We use a debugger to examine state information while the simulation is running to try to determine problem causes. Note that the GCC project is based on volunteers, so your PR may never get the high priority attention that you apparently require. For such critical usage, you may consider getting support for your compiler (or get familiar with the compiler to investigate this issue yourself). I thought I read in the submission guidelines that an attachment was acceptable in a case like this. If I should submit the file contents as a large file, please point me to a sample so I know how to format the various individual file contents. Having a tar file for sources is certainly fine. Having all the instructions and explanation inside a README in a tarball is an unnecessary indirection which can only delay review of your PR. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880
[Bug c/35885] unsigned long long and while loop evaluation regression?
--- Comment #2 from wilbert at jdg dot info 2008-04-09 15:36 --- I just did a fresh build of gcc 4.1.3 from the ports collection under freebsd 6.1 And got this (incorrect) result again: before: testu64a = 9afa246709018f48, testu32a = 0506f85f after: testu64a = 9afa246709018f48, testu32a = 0506f85f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35885
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #53 from bergner at gcc dot gnu dot org 2008-04-09 15:38 --- Author: bergner Date: Wed Apr 9 13:42:43 2008 New Revision: 134139 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134139 Log: PR middle-end/PR28690 * explow.c (break_out_memory_refs): Use simplify_gen_binary rather than gen_rtx_fmt_ee to perform more canonicalizations. Modified: trunk/gcc/ChangeLog trunk/gcc/explow.c -- bergner at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/35890] __attribute__((format)) fails for methods of template classes
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-09 15:53 --- *** This bug has been marked as a duplicate of 35546 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35890
[Bug c++/35546] [4.3/4.4 Regression] __attribute__(format...) broken for members of template classes?
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-09 15:53 --- *** Bug 35890 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35546
[Bug c++/35890] New: __attribute__((format)) fails for methods of template classes
The following code, which compiles cleanly in gcc 4.2.3, produces an error with
4.3.0:
template typename T
struct X {
void f(const char *fmt, ...)
__attribute__((format (printf, 2, 3) ));
};
template class X void ;
fmt_et.cc: In instantiation of 'Xvoid':
fmt_et.cc:7: instantiated from here
fmt_et.cc:4: error: 'printf' was not declared in this scope
fmt_et.cc:4: error: unrecognized format specifier
The error occurs both with explicit instantiation of the class (as above) and
with implicit instantiation via an invocation of the method Xvoid::f. It
does not occur either for a non-template class or if the template is never
instantiated.
--
Summary: __attribute__((format)) fails for methods of template
classes
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
GCC build triplet: x86_64_pc_linux_gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64_pc_linux_gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35890
[Bug c++/35708] jump to label enters catch block
--- Comment #8 from jason at gcc dot gnu dot org 2008-04-09 16:16 --- Subject: Bug 35708 Author: jason Date: Wed Apr 9 16:15:53 2008 New Revision: 134146 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134146 Log: PR c++/35708 * semantics.c (finish_compound_literal): Return a TARGET_EXPR, not a pushed variable. Added: trunk/gcc/testsuite/g++.dg/ext/complit9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory
--- Comment #6 from knoxj at att dot net 2008-04-09 16:19 ---
Thank you for your comments. This is my first free software bug report, so I'm
still learning the ropes. I have been submitting commercial vendor bug reports
for several decades, and old habits die hard.
README file contents :
The files listed below demonstrate the GNAT Ada compiler not generating 'gdb'
debug information correctly for shared memory.
'gdb' says
No definition of pacs_cp in current context.
NightView says
Identifier pacs_cp is not visible in the given context.
Problem first found on 2.6.18.8-RedHawk-4.2.2-trace
gdb Concurrent RedHawk Linux (6.3.0.0-1.63rh)
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
Problem verified on2.6.15.4-RedHawk-4.1-debug
gdb Concurrent RedHawk Linux (6.3.0.0-1.63rh)
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
Problem verified on2.6.9-RedHawk-2.3.5-debug
gdb 6.0
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)
Problem verified on2.6.9-42.0.3.EL (Red Hat EL WS 4 update 4)
gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
Problem verified on2.6.23.1-42.fc8
gdb Fedora (6.8-1.fc9)
gcc version 4.3.0 20080326 (Red Hat 4.3.0-5) (GCC)
===
makefile - build rules
ada_proclock.ads - Ada interface
proclock.h - C interface
proclock.c - C implementation
f15_shm.ld - 'ld' commands for shared memory layout
f15_shm.h- C interface
f15_shm.c- C implementation
f15_shm_tables.c - shared memory data tables
nh_base_types.ads- hardware representation
test_pacs_cp_package.ads - Ada data description
testshm.adb - Ada test program
pacs_cp.h - C data description
testshmc.c - C test program
===
Follow the steps below to reproduce the problem :
1. make clean
2. make
3. gdb testshma
'tb main'
'r'
'n' 7 times to get to Ada_Main_Program
's'
'n' 4 times
'ptype pacs_cp' to get No definition of pacs_cp in current context.
4. gdb testshmc
'tb main'
'r'
'n' 4 times
'ptype pacs_cp' to get type = volatile struct PACS_CP {
short int word[8192];
}
5. edit test_pacs_cp_package.ads
comment pragma IMPORT line
6. make
7. gdb testshma
'tb main'
'r'
'n' 7 times to get to Ada_Main_Program
's'
'n' 4 times
'ptype pacs_cp' to get type = record
word: array (1 .. 8192) of
nh_base_types.signed_half_word_type;
end record
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880
[Bug objc++/35891] New: wrong pointer type in build_module_initializer_routine?
I'm in the process of merging ObjC 2.0 Apple stuff into gcc 4.3.0 for the cocotron project; we build a cross-compiler to build Windows/Linux binaries from Darwin. In the progress we got an ICE when compiling any ObjC++ code that would cause an __objc_gnu_init constructor to be emitted with optimizations: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c: 1535. While trying to fix this problem, I noticed that build_module_initializer_routine contains the line objc_push_parm (build_decl (PARM_DECL, NULL_TREE, void_type_node)); Replacing this with #ifdef OBJCPLUS objc_push_parm (build_decl (PARM_DECL, NULL_TREE, ptr_type_node)); #else objc_push_parm (build_decl (PARM_DECL, NULL_TREE, void_type_node)); #endif fixed the problem. I don't have the first idea on why; maybe this is just masking a deeper problem. It certainly seems wrong somehow (the __objc_gnu_init should take a void, shouldn't it?)... Maybe someone with more knowledge on gcc stuff could shed a little light on this? -- Summary: wrong pointer type in build_module_initializer_routine? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: johannes dot fortmann at gmail dot com GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i386-mingw32msvc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35891
[Bug libstdc++/35588] [parallel mode] parallel std::sort and bind()
--- Comment #4 from singler at gcc dot gnu dot org 2008-04-09 16:47 --- Subject: Bug 35588 Author: singler Date: Wed Apr 9 16:47:00 2008 New Revision: 134148 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134148 Log: 2008-04-09 Johannes Singler [EMAIL PROTECTED] * include/parallel/multiway_merge.h: Moved decisions to compiletime instead of runtime. * include/parallel/losertree.h: Removed obsolete variants, added variant that uses pointers in the loser tree. * include/parallel/types.h: Remove obsolete settings options from enum. * include/parallel/features.h: Remove obsolete compile-time switches. * include/parallel/compiletime_settings.h: Remove obsolete variant that copies back *after* sorting. * include/parallel/tags.h: Add one new tag for compile-time switch. * include/parallel/merge.h: Adapt to changes in multiway_merge.h. * include/parallel/multiway_mergesort.h: Adapt to changes in multiway_merge.h. Factor out splitting variants. Remove obsolete variant that copies back *after* sorting. * include/parallel/sort.h: Adapt to changes in multiway_mergesort.h. * testsuite/25_algorithms/sort/35588.cc: Added test case from / for PR 35588. Added: branches/gcc-4_3-branch/libstdc++-v3/testsuite/25_algorithms/sort/35588.cc Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/include/parallel/compiletime_settings.h branches/gcc-4_3-branch/libstdc++-v3/include/parallel/features.h branches/gcc-4_3-branch/libstdc++-v3/include/parallel/losertree.h branches/gcc-4_3-branch/libstdc++-v3/include/parallel/merge.h branches/gcc-4_3-branch/libstdc++-v3/include/parallel/multiway_merge.h branches/gcc-4_3-branch/libstdc++-v3/include/parallel/multiway_mergesort.h branches/gcc-4_3-branch/libstdc++-v3/include/parallel/sort.h branches/gcc-4_3-branch/libstdc++-v3/include/parallel/tags.h branches/gcc-4_3-branch/libstdc++-v3/include/parallel/types.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35588
[Bug fortran/35892] New: gfortran dies on file containing module and common
Compilation with -O0 -g causes the compiler to crash: /opt/gcc/bin/gfortran -c -fno-second-underscore -fdefault-integer-8 -m64 -g -O0 --save-temps f12_integrals.f f12_integrals.f: In function 'f12_integrals_raw': f12_integrals.f:980: internal compiler error: in expand_expr_real_1, at expr.c:7258 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Using built-in specs. Target: i386-apple-darwin9.2.2 Configured with: ../configure --prefix=/opt/gcc --enable-languages=c,fortran : (reconfigured) ../configure --prefix=/opt/gcc --enable-languages=c,fortran --no-create --no-recursion Thread model: posix gcc version 4.4.0 20080409 (experimental) (GCC) Although gcc -v reports 'i386' this is in fact an x86_64. But compiling on a true ia32 (and omitting -m64) produces the same crash. With -g removed or -O1 the compiler completes. However we are getting wrong results, so perhaps the place to start is with the crash and then try again? -- Summary: gfortran dies on file containing module and common Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: KnowlesPJ at Cardiff dot ac dot uk GCC host triplet: i386-apple-darwin9.2.2 GCC target triplet: i386-apple-darwin9.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug fortran/35892] gfortran dies on file containing module and common
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-09 17:24 --- Created an attachment (id=15458) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15458action=view) Fortran source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug libstdc++/35588] [parallel mode] parallel std::sort and bind()
--- Comment #5 from singler at gcc dot gnu dot org 2008-04-09 17:03 --- Fixed for mainline and gcc-4_3-branch. -- singler at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35588
[Bug c++/35876] Exceptions not working on FreeBSD
--- Comment #1 from yuri at tsoft dot com 2008-04-09 18:06 --- After further investigation it appears to be some issue with exceptions in FreeBSD-STABLE-7.0 system g++ compiler. Exceptions don't work on FreeBSD with system compiler at all. System compiler is a version of gcc-4.2.1 tweaked by FreeBSD folks in some way so let's leave it alone. But gcc-4.3.0 was freshly compiled by me. And with gcc-4.3.0 exceptions only work when -pthread flag is set (on FreeBSD only). Without -pthread flag gcc-4.3.0 has a problem with exceptions (using it's own gcc-4.3.0 shared libraries). Error is: Abort trap: 6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug testsuite/35868] Errors with hard_float
--- Comment #1 from hp at gcc dot gnu dot org 2008-04-09 18:08 --- honza's bug; cc:ed. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35868
[Bug middle-end/35843] [4.4 Regression]: gcc.dg/pr30957-1.c and gcc.dg/var-expand1.c don't work
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-09 18:10 --- *** Bug 35868 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35843
[Bug testsuite/35868] Errors with hard_float
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-09 18:10 --- *** This bug has been marked as a duplicate of 35843 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35868
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #2 from jaydub66 at gmail dot com 2008-04-09 18:23 --- Here is a modified version of the original test case, which is also accepted by gfortran, while it is rejected by ifort: module m contains subroutine one(a) integer a(1:2) end subroutine one subroutine two(a) integer a(2:3) end subroutine two end module program test use m implicit none ! PROCEDURE dummy !call foo(two) ! Interface dummy call bar(two) contains ! subroutine foo(f) ! procedure(one) :: f ! end subroutine foo subroutine bar(f) interface subroutine f(a) integer a(1:2) end subroutine f end interface end subroutine bar end program test In this test case both arrays are explicit-sized, and even have the same size, but their upper and lower bounds are shifted. gfortran currently does not even check if both arrays have the same size, only their ranks are compared. ifort gives the following error message: fortcom: Error: test35831.f90, line 23: The characteristics of dummy argument 1 of the associated actual procedure differ from the characteristics of dummy argument 1 of the dummy procedure. (12.2) [TWO] call bar(two) ---^ I would change this bug's status from UNCONFIRMED to NEW, but apparently I don't have the canconfirm permission. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments
--- Comment #5 from jaydub66 at gmail dot com 2008-04-09 18:48 --- (In reply to comment #4) If we are lucky this fixes PR 35831. Actually it does not, but I think I know how to fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-09 18:49 --- In this test case both arrays are explicit-sized, and even have the same size, but their upper and lower bounds are shifted. gfortran currently does not even check if both arrays have the same size, only their ranks are compared. I think procedures with explicit-shape arguments with the same shape/size but only different bounds should be conformable. The only real problem is assumed-shape vs. the rest (explict, assumed-size, ...). Ok, if an explicit size is given, the sizes should match, but arguments of the dummy/actual function like integer :: foo(*) and bar(1:2) and foobar(3000:3001) should all be conformable. Similarly, I think, also foo(1:), bar(:) and foobar(-300:) should be conformable. (I cannot really pinpoint it in the standard, but I'm convinced that this is the case; when I have time, I will re-read the standard and try to produce a proper reference.) * I use manner as kind and type have a special Fortran meaning. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-09 18:49:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common
--- Comment #2 from burnus at gcc dot gnu dot org 2008-04-09 18:31 --- Confirm. Seems to be introduced between 2008-04-03-r133863 and 2008-03-27-r133632. I tried to reduce the test case -- and I failed. I think somewhere the memory gets corrupted. ==1454== Invalid read of size 2 ==1454==at 0x5CEB69: fold_binary (fold-const.c:9920) ==1454==by 0x5D8188: fold_build2_stat (fold-const.c:13441) ==1454==by 0x4A7752: gfc_conv_expr_op (trans-expr.c:1229) ==1454==by 0x4A6117: gfc_conv_expr_val (trans-expr.c:3612) ==1454==by 0x4A986B: gfc_conv_intrinsic_function_args (trans-intrinsic.c:193) ==1454==by 0x4B13A0: gfc_conv_intrinsic_minmax (trans-intrinsic.c:1442) ==1454==by 0x4B27F0: gfc_conv_intrinsic_function (trans-intrinsic.c:4309) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i386-apple-darwin9.2.2 | GCC target triplet|i386-apple-darwin9.2.2 | Keywords||ice-on-valid-code Known to fail||4.4.0 Known to work||4.3.0 4.2.3 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-04-09 18:31:35 date|| Summary|gfortran dies on file |[4.4 regression] gfortran |containing module and common|dies on file containing ||module and common Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug target/35860] code bloat caused by -fsplit-wide-types
--- Comment #2 from eric dot weddington at atmel dot com 2008-04-09 19:04 --- I'll see about testing with Andy Hutchinson's fwprop patch at bug #35542. -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||hutchinsonandy at aim dot ||com, eric dot weddington at ||atmel dot com GCC host triplet|winavr 20080402 release |mingw http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #32 from fche at redhat dot com 2008-04-09 19:15 --- The patch has been committed for some time, and this test case passes. -- fche at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug target/35860] code bloat caused by -fsplit-wide-types
--- Comment #3 from hutchinsonandy at aim dot com 2008-04-09 19:24 --- Subject: Re: code bloat caused by -fsplit-wide-types Try fwprop patch it might well help. I can't tell from report where the oppertunities are missed. But anything split at combine/split won't get any benefit as fwprop passes only occur before (much to my dismay). Register allocation has a more limited forward propagtion ability (it does not simplify for one) and simplistical will remove one level of redundant moves. If we try split before combine (expanded RTL), then combine does work so well and it's a net loss. Combine on split types does not work well as it is not possible to all instructions (like compare, add). We can't split due to use of CC0. We use CC0 because I cant figure out how to prevent reloads destroying status. Dang it! -Original Message- From: eric dot weddington at atmel dot com [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed, 9 Apr 2008 3:04 pm Subject: [Bug target/35860] code bloat caused by -fsplit-wide-types --- Comment #2 from eric dot weddington at atmel dot com 2008-04-09 19:04 --- I'll see about testing with Andy Hutchinson's fwprop patch at bug #35542. -- eric dot weddington at atmel dot com changed: What|Removed |Added - --- CC||hutchinsonandy at aim dot ||com, eric dot weddington at ||atmel dot com GCC host triplet|winavr 20080402 release |mingw http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug c/35893] New: ice for legal code
I just tried to compile the Suse Linux package smalltalk-2.1.12 with the GNU C compiler version 4.4 snapshot 20080404 The compiler said gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib-src -I../lightning -I../lightning -I../snprintfv -I../snprintfv -DKERNEL_PATH=\/usr/share/smalltalk/kernel\ -Wall -DIMAGE_PATH=\/usr/share/smalltalk\ -DMODULE_PATH=\/usr/lib64/smalltalk\ -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -Wall -Wdeclaration-after-statement -Wno-format -Wno-parentheses -Wpointer-arith -Wno-pointer-sign -Wno-strict-aliasing -Wno-switch -fno-gcse -fno-strict-aliasing -MT oop.lo -MD -MP -MF .deps/oop.Tpo -c oop.c -o oop.o oop.c: In function '_gst_mark_an_oop_internal': oop.c:2060: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -Wall required Here is some additional help from valgrind ==2919== Invalid read of size 2 ==2919==at 0x42588E: emit_side_effect_warnings (c-typeck.c:7522) ==2919==by 0x42DB50: c_finish_stmt_expr (c-typeck.c:7670) ==2919==by 0x47ACB7: c_parser_postfix_expression (c-parser.c:5230) ==2919==by 0x47AEEE: c_parser_unary_expression (c-parser.c:4982) ==2919==by 0x47B91C: c_parser_cast_expression (c-parser.c:4857) ==2919==by 0x47B9A4: c_parser_cast_expression (c-parser.c:4850) ==2919==by 0x47BA6D: c_parser_conditional_expression (c-parser.c:4687) ==2919==by 0x47C254: c_parser_expr_no_commas (c-parser.c:4448) ==2919==by 0x47C441: c_parser_expression (c-parser.c:5695) ==2919==by 0x47A42D: c_parser_postfix_expression (c-parser.c:5257) ==2919==by 0x47AEEE: c_parser_unary_expression (c-parser.c:4982) ==2919==by 0x47B91C: c_parser_cast_expression (c-parser.c:4857) ==2919== Address 0x0 is not stack'd, malloc'd or (recently) free'd -- Summary: ice for legal code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35893
[Bug c/35893] ice for legal code
--- Comment #1 from dcb314 at hotmail dot com 2008-04-09 19:40 --- Created an attachment (id=15459) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15459action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35893
[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error
--- Comment #5 from laguest at archangeli dot demon dot co dot uk 2008-04-09 19:45 --- This is still a problem on 4.4.0 trunk. Luke. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
[Bug c++/35708] jump to label enters catch block
--- Comment #9 from jason at gcc dot gnu dot org 2008-04-09 19:58 --- Subject: Bug 35708 Author: jason Date: Wed Apr 9 19:57:19 2008 New Revision: 134151 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134151 Log: PR c++/35708 * semantics.c (finish_compound_literal): Return a TARGET_EXPR, not a pushed variable. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/complit9.C - copied unchanged from r134146, trunk/gcc/testsuite/g++.dg/ext/complit9.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/semantics.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c++/35708] jump to label enters catch block
--- Comment #10 from jason at gcc dot gnu dot org 2008-04-09 20:10 --- Fixed for 4.3.1 and 4.4.0. Patch seems risky for 4.2 at this point. -- jason at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.3 |4.1.3 4.3.1 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error
--- Comment #6 from ludovic at ludovic-brenta dot org 2008-04-09 20:10 --- Reduced test case: package Observers is type Observer is tagged null record; type Observer_Access is access all Observers.Observer'Class; end Observers; limited with Observers; with Ada.Containers.Doubly_Linked_Lists; package Subjects is function Equals(Left, Right : access Observers.Observer) return Boolean; package Observer_Lists is new Ada.Containers.Doubly_Linked_Lists(Observers.Observer_Access, Equals); end Subjects; with Observers; -- this line triggers the bug package body Subjects is function Equals(Left, Right : access Observers.Observer) return Boolean is begin return False; end Equals; end Subjects; With the line that triggers the bug: gcc-4.1 -c -gnat05 subjects.adb +===GNAT BUG DETECTED==+ | 4.1.3 20070518 (prerelease) (Debian 4.1.2-8) (x86_64-pc-linux-gnu) | | Assert_Failure atree.adb:812 | | Error detected at subjects.ads:8:3 | gcc-4.3 -c -gnat05 subjects.adb +===GNAT BUG DETECTED==+ | 4.3.1 20080401 (prerelease) (x86_64-pc-linux-gnu) Assert_Failure atree.adb:886| | Error detected at subjects.ads:8:3 | Without the line that triggers the bug: gcc-4.1 -c -gnat05 subjects.adb subjects.ads:9:49: premature use of incomplete type subjects.ads:9:49: instantiation abandoned gcc-4.3 -c -gnat05 subjects.adb subjects.ads:9:49: premature use of incomplete type subjects.ads:9:49: instantiation abandoned -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error
--- Comment #7 from ludovic at ludovic-brenta dot org 2008-04-09 20:25 --- Further reduced test case: replace observers.ads with: package Observers is type Observer is new Integer; type Observer_Access is access Observer; end Observers; and the bug is still there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error
--- Comment #8 from sam at gcc dot gnu dot org 2008-04-09 20:40 --- Yes, the bug manifests when the view on the type is limited at this point *but* we know the underlying type (because of a non-limited with for example). This triggers it if you compile p2.adb: package P1 is type T is null record; end P1; limited with P1; package P2 is pragma Elaborate_Body; generic type T is private; package G is end G; package I1 is new G (P1.T); end P2; with P1; package body P2 is end P2; I'm testing a fix. -- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-07 14:01:58 |2008-04-09 20:40:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
[Bug c/35894] New: ICE in calc_dfs_tree, at dominance.c:393
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c-O3 ati_fragment_shader.i ati_fragment_shader.i: In function 'g': ati_fragment_shader.i:39: internal compiler error: in calc_dfs_tree, at dominance.c:393 -- Summary: ICE in calc_dfs_tree, at dominance.c:393 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: i686-pc-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=35894
[Bug c/35894] ICE in calc_dfs_tree, at dominance.c:393
--- Comment #1 from marcus at jet dot franken dot de 2008-04-09 21:53 --- Created an attachment (id=15460) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15460action=view) ati_fragment_shader.i gcc -c -O3 ati_fragment_shader.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35894
