[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #6 from pluto at agmk dot net 2006-09-04 06:33 --- (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > > > > > > > > this is gnu c++ extension: > > > > Yes but you are using the extension incorrectly anyways as you don't pass > > this > > to the function. Did you read that page? > > > > extern A a; > > extern int (A::*fp)(); > > typedef int (*fptr)(A *); > > > > fptr p = (fptr)(a.*fp); > > > > While you do: > > pf f1 = (pf)( o->*pmf ); > > f1(); > > > > Really it should have been: > > f1(o); > > compiler reports an error now. > test.cpp:18: error: too many arguments to function > aaa, sorry. please ignore this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #5 from pluto at agmk dot net 2006-09-04 06:33 --- (In reply to comment #4) > (In reply to comment #3) > > > > > > > this is gnu c++ extension: > > Yes but you are using the extension incorrectly anyways as you don't pass this > to the function. Did you read that page? > > extern A a; > extern int (A::*fp)(); > typedef int (*fptr)(A *); > > fptr p = (fptr)(a.*fp); > > While you do: > pf f1 = (pf)( o->*pmf ); > f1(); > > Really it should have been: > f1(o); compiler reports an error now. test.cpp:18: error: too many arguments to function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-04 06:13 --- Ok, I have a more correct patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 06:06 --- (In reply to comment #3) > > > > this is gnu c++ extension: Yes but you are using the extension incorrectly anyways as you don't pass this to the function. Did you read that page? extern A a; extern int (A::*fp)(); typedef int (*fptr)(A *); fptr p = (fptr)(a.*fp); While you do: pf f1 = (pf)( o->*pmf ); f1(); Really it should have been: f1(o); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #3 from pluto at agmk dot net 2006-09-04 06:01 --- (In reply to comment #2) > t.cc: In function ‘void test(base*, void (base::*)())’: > t.cc:19: error: converting from ‘void (base::)()’ to ‘void > (*)()’ > > Why do you think this is valid thing to do? > > There is no way to get a normal function pointer from a pointer to member > function. > this is gnu c++ extension: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Bound-member-functions.html#Bound-member-functions -- pluto at agmk dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug libgomp/28926] FAIL: libgomp.c/ordered-1.c execution test
--- Comment #1 from uros at kss-loka dot si 2006-09-04 05:49 --- The problem is that RH8.0 defines SYS_gettid and SYS_futex in headers although futex syscall is not really supported in the kernel. The build process detects this and issues a warning to configure with --disable-linux-futex, but still defaults to use futex syscall. Perhaps futex support detection logic in libgomp/configure.ac (around line 200) should be reversed, so it would default to "don't use futex by default, but use them if all tests pass". Anyway, --disable-linux-futex works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28926
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-04 04:40 --- Actually complete unrolling is not at fault but cleanup cfg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-04 04:12 --- (In reply to comment #5) > Subject: Re: [4.2 regression] ICE in add_virtual_operand, at > tree-ssa-operands.c:1309 > > Why does loop change the SMT usage? it is complete unrolling, we change the statements from a loop to something like, where the constants are really folded (I am too lazy to fold it here): _buffer[64 - 8] = (unsigned char)lenInBits; _buffer[64 - 8+1] = (unsigned char)lenInBits; > In addition, since there are times loop doesn't do anything, you > should simply be returning PROP_smt_usage when it does do something, > and nothing otherwise. I will see if I can change unroller to return true if we did something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-09-04 04:06 --- Subject: Re: [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309 Why does loop change the SMT usage? In addition, since there are times loop doesn't do anything, you should simply be returning PROP_smt_usage when it does do something, and nothing otherwise. On 4 Sep 2006 03:52:04 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 03:52 > --- > Note the patch is: > Index: tree-ssa-loop.c > === > --- tree-ssa-loop.c (revision 116671) > +++ tree-ssa-loop.c (working copy) > @@ -405,9 +405,11 @@ struct tree_opt_pass pass_complete_unrol >TV_COMPLETE_UNROLL, /* tv_id */ >PROP_cfg | PROP_ssa, /* properties_required */ >0, /* properties_provided */ > - 0, /* properties_destroyed */ > + PROP_smt_usage, /* properties_destroyed */ >0, /* todo_flags_start */ > - TODO_dump_func | TODO_verify_loops, /* todo_flags_finish */ > + TODO_dump_func > +| TODO_verify_loops > +| PROP_smt_usage, /* todo_flags_finish */ >0/* letter */ > }; > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937 > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
Re: [Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
Why does loop change the SMT usage? In addition, since there are times loop doesn't do anything, you should simply be returning PROP_smt_usage when it does do something, and nothing otherwise. On 4 Sep 2006 03:52:04 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 03:52 --- Note the patch is: Index: tree-ssa-loop.c === --- tree-ssa-loop.c (revision 116671) +++ tree-ssa-loop.c (working copy) @@ -405,9 +405,11 @@ struct tree_opt_pass pass_complete_unrol TV_COMPLETE_UNROLL, /* tv_id */ PROP_cfg | PROP_ssa, /* properties_required */ 0, /* properties_provided */ - 0, /* properties_destroyed */ + PROP_smt_usage, /* properties_destroyed */ 0, /* todo_flags_start */ - TODO_dump_func | TODO_verify_loops, /* todo_flags_finish */ + TODO_dump_func +| TODO_verify_loops +| PROP_smt_usage, /* todo_flags_finish */ 0/* letter */ }; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-04 03:52 --- Note the patch is: Index: tree-ssa-loop.c === --- tree-ssa-loop.c (revision 116671) +++ tree-ssa-loop.c (working copy) @@ -405,9 +405,11 @@ struct tree_opt_pass pass_complete_unrol TV_COMPLETE_UNROLL, /* tv_id */ PROP_cfg | PROP_ssa, /* properties_required */ 0, /* properties_provided */ - 0, /* properties_destroyed */ + PROP_smt_usage, /* properties_destroyed */ 0, /* todo_flags_start */ - TODO_dump_func | TODO_verify_loops, /* todo_flags_finish */ + TODO_dump_func +| TODO_verify_loops +| PROP_smt_usage, /* todo_flags_finish */ 0/* letter */ }; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-04 03:47 --- I have the simple obvious fix for this bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-04 03:02 --- The fold is still needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-04 02:58
---
What about this (which makes us not call fold unless we really need to):
Index: pt.c
===
--- pt.c(revision 116671)
+++ pt.c(working copy)
@@ -10631,10 +10631,15 @@ unify (tree tparms, tree targs, tree par
not an integer constant. */
if (TREE_CODE (parm_max) == MINUS_EXPR)
{
- arg_max = fold_build2 (PLUS_EXPR,
-integer_type_node,
-arg_max,
-TREE_OPERAND (parm_max, 1));
+ if (TREE_CODE (arg_max) == MINUS_EXPR
+ && simple_cst_equal (TREE_OPERAND (arg_max, 1),
+ TREE_OPERAND (parm_max, 1)))
+ arg_max = TREE_OPERAND (arg_max, 0);
+ else
+ arg_max = fold_build2 (PLUS_EXPR,
+ integer_type_node,
+ arg_max,
+ TREE_OPERAND (parm_max, 1));
parm_max = TREE_OPERAND (parm_max, 0);
}
Though I wonder if the fold is even needed. I am testing a couple of testcase
and see if it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug c++/28903] [4.2 Regression] Rejects VLA in template class's member with using
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-04 02:32 --- The problem is here: /* The array dimension behaves like a non-type template arg, in that we want to fold it as much as possible. */ max = tsubst_template_arg (omax, args, complain, in_decl); max = fold_decl_constant_value (max); It actually does not behave like one if we the decl is inside a function so that you can use VLAs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28903
[Bug c++/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-04 00:59 --- t.cc: In function void test(base*, void (base::*)()): t.cc:19: error: converting from void (base::)() to void (*)() Why do you think this is valid thing to do? There is no way to get a normal function pointer from a pointer to member function. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|other |c++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug other/28945] extracting the function pointer from a bound pointer to member function doesn't work.
--- Comment #1 from pluto at agmk dot net 2006-09-04 00:00 --- as far as i can see the `this` pointer wasn't adjusted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug tree-optimization/28944] tree-dce incorrectly removes an assignment.
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-09-03 23:50 --- Subject: Re: New: tree-dce incorrectly removes an assignment. > asm volatile > ( > "push %1 \n\t" > "call *%0 \n\t" > "add$4, %%esp \n\t" > : > : "r" ( &test ), "r" ( &x ) > ); asm statements are not allowed to alter control flow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28944
Re: [Bug tree-optimization/28944] New: tree-dce incorrectly removes an assignment.
asm volatile ( "push %1 \n\t" "call *%0 \n\t" "add$4, %%esp \n\t" : : "r" ( &test ), "r" ( &x ) ); asm statements are not allowed to alter control flow
[Bug other/28945] New: extracting the function pointer from a bound pointer to member function doesn't work.
following testcase should work but it fails at least on ia32.
#include
struct base
{
virtual ~base() { }
virtual void foo() = 0;
int val;
};
struct derived : public base
{
void foo()
{
std::printf( "foo(): this -> %p, val = %d\n",
(void*)this, val );
}
};
typedef void (* pf)();
void test( base* o, void (base::* pmf)() )
{
pf f1 = (pf)( o->*pmf );
f1();
}
int main()
{
derived object;
object.val = 7;
test( &object, &base::foo );
return 0;
};
$ g++ test.cpp -Wall -Wno-pmf-conversions -m32 -O0 && ./a.out
foo(): this -> 0xf7cd2412, val = -2046820353
$ g++ test.cpp -Wall -Wno-pmf-conversions -m32 -O1 && ./a.out
foo(): this -> 0xf7fbf6e0, val = -134501465
$ g++ test.cpp -Wall -Wno-pmf-conversions -m32 -O2 && ./a.out
foo(): this -> 0xceec, val = 7
$ g++ test.cpp -Wall -Wno-pmf-conversions -m64 -O0 && ./a.out
foo(): this -> 0x7f8afe20, val = 7
$ g++ test.cpp -Wall -Wno-pmf-conversions -m64 -O1 && ./a.out
foo(): this -> 0x7fe3af40, val = 7
$ g++ test.cpp -Wall -Wno-pmf-conversions -m64 -O2 && ./a.out
foo(): this -> 0x7fb443e0, val = 7
--
Summary: extracting the function pointer from a bound pointer to
member function doesn't work.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: ix86-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28945
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 21:05 --- Hmm: # Since gcc_tooldir does not exist at build-time, use -B$(build_tooldir)/bin/ build_tooldir = $(exec_prefix)/$(target_noncanonical) Why do you think this wrong? -B. is suppied first so this is not a bug, the order of looking for files is the order at which the -B are supplied. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug middle-end/26942] Code generation bug -freorder-blocks-and-partition
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-03 20:55 --- (In reply to comment #3) > Fixed in 4.1.2. By: 2006-08-31 Roger Sayle <[EMAIL PROTECTED]> PR other/22313 * dwarf2out.c (add_fde_cfi): Use a set_loc if the current label is NULL, otherwise use an advance_loc4 to adjust relative to the current label. (output_cfi) : Update the current label. (dwarf2out_switch_text_section): Reset the current label to avoid using advance_loc4 over section boundaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26942
[Bug middle-end/26942] Code generation bug -freorder-blocks-and-partition
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-03 20:54 --- Fixed in 4.1.2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26942
[Bug middle-end/26196] optimize if(val>max) val=max;
--- Comment #6 from snakebyte at gmx dot de 2006-09-03 20:53 --- marked as wontfix since my benchmark is useless -- snakebyte at gmx dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26196
[Bug target/26149] libgomp.c/ordered-2.c fails on x86-64-linux-gnu with -m32
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 20:50 --- Still fails as of today: http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00141.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-03 20:50:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26149
[Bug middle-end/26196] optimize if(val>max) val=max;
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-03 20:45 --- (In reply to comment #4) > wow, thats a fast reply. You got a pointer on how to warm the branch > prediction > cache or is this all a no-issue an we can mark this as not a bug? Yes by doing it in a loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26196
[Bug tree-optimization/28944] tree-dce incorrectly removes an assignment.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 20:39 --- The inline-asm is incorrect as it does not tell the compiler it is going to use the value inside the pointers, it should be changed to something like: asm volatile ( "push %2 \n\t" "call *%1 \n\t" "add$4, %%esp \n\t" :"+m"(x)" : "r" ( &test ), "r" ( &x ),) ); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28944
[Bug c/24010] [4.0/4.1/4.2 Regression] Duplicate C99 dot initializer warning missing
--- Comment #3 from segher at kernel dot crashing dot org 2006-09-03 20:39 --- The overwriting behaviour is required by 6.7.8/18 and 19. A warning is certainly in order; long ago, GCC used to warn, and bugs were caught because of that. Not anymore... I'll see if I can do a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #6 from lindevel at gmx dot net 2006-09-03 20:38 --- Perhaps the message should then be "0 (int) is of incompatible type to debug(...) (void)" or similar? At least it should be more clear about the fact that the error is that both sides of the : need to be compatible (and are not). I though about all kinds of other things, but not of an incompatibility, because the error message tells me about void and throw expressions and not about the specs for (?:). Don't get me wrong, I don't want g++ to output a C++ beginners manual, but at least it should be clear from an error message where the error is, otherwise the message is useless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
[Bug tree-optimization/28944] New: tree-dce incorrectly removes an assignment.
#ifdef __i386__
#include
struct obj
{
void foo()
{
std::printf( "foo(): this -> %p, val = %d\n",
(void*)this, val );
}
int val;
};
void test( obj& o )
{
o.foo();
}
int main()
{
obj x;
x.val = 7;
asm volatile
(
"push %1 \n\t"
"call *%0 \n\t"
"add$4, %%esp \n\t"
:
: "r" ( &test ), "r" ( &x )
);
return 0;
};
#endif
$ g++ test.cpp -m32 -Wall -O1 && ./a.out
foo(): this -> 0xc610, val = -135843852
$ g++ test.cpp -m32 -Wall -O1 -fno-tree-dce && ./a.out
foo(): this -> 0xcfd0, val = 7
--
Summary: tree-dce incorrectly removes an assignment.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: ix86-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28944
[Bug target/23909] Incorrect code generated for SSE2 based xor routine when compiled with -O2 -fomit-frame-pointer
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-03 20:30 --- __asm__ __volatile__( "add %1, %0\n" "movaps 0(%0), %%xmm0\n" "movaps 16(%0), %%xmm1\n" : : "r" (bptr[0]), "r" (offset)); This asm is wrong, it does not tell the compiler that it modifies memory or even xmmm? registers. Really you should be using SSE instrincs functions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 20:25 --- This looks like the same bug as PR 22231. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||22231 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug middle-end/21259] ICE on assigning the pointer to a array with __attribute__ aligned
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 20:19 --- Fixed in 4.0.0, 3.4.x is no longer maitained. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21259
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #5 from pinskia at physics dot uc dot edu 2006-09-03 20:18 --- Subject: Re: Unusable error message when using a conditional-expression with multiple type arguments On Sun, 2006-09-03 at 20:08 +, lindevel at gmx dot net wrote: > > --- Comment #4 from lindevel at gmx dot net 2006-09-03 20:08 --- > You proved ##c++ wrong! They bet that I would be ignored. ;) > > The thing is that a void itself is not invalid. Using (expr ? void : void) > works as you see in my report. > In ##c++ I was told that ( x ? y : z ) wants both y and z to be of the same > type. And that is stated in no way by the error message. void is valid if the both sides of the : are void, otherwise it is invalid. And they don't have to be the same type either, they can be different as long as one is convertible to the other (like float and int or two classes where one is a base class of the other). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
Re: [Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
On Sun, 2006-09-03 at 20:08 +, lindevel at gmx dot net wrote: > > --- Comment #4 from lindevel at gmx dot net 2006-09-03 20:08 --- > You proved ##c++ wrong! They bet that I would be ignored. ;) > > The thing is that a void itself is not invalid. Using (expr ? void : void) > works as you see in my report. > In ##c++ I was told that ( x ? y : z ) wants both y and z to be of the same > type. And that is stated in no way by the error message. void is valid if the both sides of the : are void, otherwise it is invalid. And they don't have to be the same type either, they can be different as long as one is convertible to the other (like float and int or two classes where one is a base class of the other). -- Pinski
[Bug c/24010] [4.0/4.1/4.2 Regression] Duplicate C99 dot initializer warning missing
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 20:13 --- The behavior was changed by: http://gcc.gnu.org/ml/gcc-patches/2001-01/msg01011.html This is valid C99 but having a warning is nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #4 from lindevel at gmx dot net 2006-09-03 20:08 --- You proved ##c++ wrong! They bet that I would be ignored. ;) The thing is that a void itself is not invalid. Using (expr ? void : void) works as you see in my report. In ##c++ I was told that ( x ? y : z ) wants both y and z to be of the same type. And that is stated in no way by the error message. And even if void would be invalid, the message doesn't tell me that. It just tells me "Hey I found a void.", but not that a void is invalid in a (?:). The connection to (?:) is not made. Instead it tells me something about a throw-expression. That might be a good message when you want to understand the internal code g++ uses to validate the expression, but for an end user it is not good. Perhaps we first should clear up what exactly the error is with that code. (I still don't know from the error message and you tell me something different than what I was told in ##c++. (Who also didn't know what that message could mean until someone said that the types don't match and g++ might be telling me how it found out.)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
[Bug c/24010] [4.0/4.1/4.2 Regression] Duplicate C99 dot initializer warning missing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 20:06 --- Confirmed, a regression from 2.95.3 which gave: t.c:8: field `a' already initialized -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Known to fail||3.0.4 4.0.0 4.1.0 4.2.0 Known to work||2.95.3 Summary|Duplicate C99 dot |[4.0/4.1/4.2 Regression] |initializer warning missing |Duplicate C99 dot ||initializer warning missing Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24010
[Bug rtl-optimization/20728] Wrong evaluation order of expressions in combine_reloads() in reload.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 20:02 --- Also do you have a testcase which hits the problem (and if you do, what target)? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20728
[Bug rtl-optimization/20728] Wrong evaluation order of expressions in combine_reloads() in reload.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 20:01 ---
reg_overlap_mentioned_for_reload_p checks for psedu registers:
/* If this is a pseudo, it must not have been assigned a hard register.
Therefore, it must either be in memory or be a constant. */
if (regno >= FIRST_PSEUDO_REGISTER)
{
if (reg_equiv_memory_loc[regno])
return refers_to_mem_for_reload_p (in);
gcc_assert (reg_equiv_constant[regno]);
return 0;
}
So is this really an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20728
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #3 from pinskia at physics dot uc dot edu 2006-09-03 19:41
---
Subject: Re: New: Unusable error message when using a
conditional-expression with multiple type arguments
On Sun, 2006-09-03 at 19:35 +, lindevel at gmx dot net wrote:
> assert_testcase.cpp: In function ‘int main()’:
> assert_testcase.cpp:16: error: ‘debug(((const char*)"Some
> string"))’ has type ‘void’ and is not a
> throw-expression
That says to me that the expression `debug("Some string")' has a type of
void (and is not a throw expression) which is invalid for ?: if the
other type is not void. I don't see where the problem is. A throw
expression is valid (here by the C++ standard) even though it has a
expression type of void.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
Re: [Bug c++/28943] New: Unusable error message when using a conditional-expression with multiple type arguments
On Sun, 2006-09-03 at 19:35 +, lindevel at gmx dot net wrote:
> assert_testcase.cpp: In function ‘int main()’:
> assert_testcase.cpp:16: error: ‘debug(((const char*)"Some
> string"))’ has type ‘void’ and is not a
> throw-expression
That says to me that the expression `debug("Some string")' has a type of
void (and is not a throw expression) which is invalid for ?: if the
other type is not void. I don't see where the problem is. A throw
expression is valid (here by the C++ standard) even though it has a
expression type of void.
-- Pinski
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #2 from lindevel at gmx dot net 2006-09-03 19:36 --- Created an attachment (id=12182) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12182&action=view) Preprocessed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #1 from lindevel at gmx dot net 2006-09-03 19:35 --- Created an attachment (id=12181) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12181&action=view) Testcase code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
[Bug c++/28943] New: Unusable error message when using a conditional-expression with multiple type arguments
When I use a conditional-expression(?:) with arguments whose type is not
matching, g++ gives an error message not telling me exactly what the problem
is.
Commandline:
g++ assert_testcase.cpp
Output:
assert_testcase.cpp: In function ‘int main()’:
assert_testcase.cpp:16: error: ‘debug(((const char*)"Some
string"))’ has type ‘void’ and is not a throw-expression
For this code (assert_testcase.cpp):
#include
void debug( const char * string )
{
printf( string );
}
int main()
{
( true == false ? 0 : debug( "Some string" ) );
return 0;
}
Changing ( true == false ? 0 : debug( "Some string" ) ) to ( true == false ?
(void)0 : debug( "Some string" ) ) silences the error message.
And that has been found out after about a week of own research in our project
and then asking in ##c++ on FreeNode, because no one had a clue what it could
mean. (And even ##c++ needed several hours to find that out.)
So I think that error message is unusable because it is not clear about what
exactly the problem is.
Better would be IMHO something like "0 is of different type than debug(...)".
Other info:
i686-pc-linux-gnu-g++ (GCC) 4.1.1 (Gentoo 4.1.1)
Preprocessed file (assert_testcase.ii) will be attached.
I can provide more information if you like.
--
Summary: Unusable error message when using a conditional-
expression with multiple type arguments
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lindevel at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
[Bug c++/28942] [4.2 Regression] Dependent deconstrcutors
--- Comment #2 from nathan at gcc dot gnu dot org 2006-09-03 18:26 --- I'll look at this tomorrow. If I can't figure out a solution I'll revert 23287 -- nathan at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-03 17:45:33 |2006-09-03 18:26:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28942
[Bug c++/28942] [4.2 Regression] Dependent deconstrcutors
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 17:45 --- Note this was from: http://gcc.gnu.org/ml/gcc/2006-09/msg00048.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-03 17:45:33 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28942
[Bug c++/28942] New: [4.2 Regression] Dependent deconstrcutors
we just reject now but it is
valid code as far as I can tell:
template< class other>
struct bin_search_tree_data_
{
typedef typename other::node node;
typedef node *node_pointer;
~bin_search_tree_data_()
{
m_p_head->~node();
}
node_pointer m_p_head;
};
struct blowup
{
typedef int node;
};
bin_search_tree_data_< blowup > r;
-- Here is one that ICEs also and closer to
the original code:
template< class other>
struct bin_search_tree_data_
{
typedef typename other::node node;
typedef node *node_pointer;
~bin_search_tree_data_()
{
m_p_head->~node();
}
node_pointer m_p_head;
};
struct blowup2{};
struct blowup
{
typedef blowup2 node;
};
bin_search_tree_data_< blowup > r;
--
I am creating this after 15 hours of no activity on fixing the problem.
--
Summary: [4.2 Regression] Dependent deconstrcutors
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, rejects-valid
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 23287
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28942
[Bug c++/23287] [4.0/4.1/4.2 regression] Explicitly invoking destructor of template class in a template and is dependent
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug tree-optimization/18687] [4.0/4.1/4.2 Regression] ~50% compile time regression
--- Comment #35 from steven at gcc dot gnu dot org 2006-09-03 17:28 --- Even if we did not hash SCEV data a lot, it would not buy you >50%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug tree-optimization/28900] [4.1/4.2 regression] ICE verify_stmts failed (invalid operand to unary operator)
--- Comment #9 from patchapp at dberlin dot org 2006-09-03 14:35 --- Subject: Bug number PR28900 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00068.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
[Bug bootstrap/28864] bootstrapping fails when building from non-/bin/sh-compatible shell
--- Comment #3 from georg dot schwarz at freenet dot de 2006-09-03 14:25 --- Unfortunately gcc 4.X.X for MIPS now requires GNU binutils as. However this triggers gcc bug #16253 on IRIX 5.3, so neither gcc 4.0.3 nor gcc 4.1.1 compiles on IRIX 5.3. -- georg dot schwarz at freenet dot de changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28864
[Bug tree-optimization/28900] [4.1/4.2 regression] ICE verify_stmts failed (invalid operand to unary operator)
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-03 14:24 --- (In reply to comment #7) > I have a patch. The vectorizer oughts to use more of the infrastructure we > have. This has nothing to do with the vectorizer really, yes tree-ifcvt is only enabled with -ftree-vectorize but it could be made even more generic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #4 from bonzini at gnu dot org 2006-09-03 13:51 --- > which ends up being "-1 < 4", so we swap the operands. For powerpc, we'd > prefer the base pointer remain the first operand for performance reasons. I'd > like other people familar with this code to comment on how we can fix this. > One could simply bump up the priority of base pointers (ie, "case RTX_OBJ:"), > but I personally don't know how that would affect other platforms. Very much. The canonical form enforced by swap_commutative_operands_p is relied upon by all the code for simplifications, that expects for example a (plus (mult A B) C) and not a (plus C (mult A B)). If one took care to fix all of them, it could work, but it's no easy feat. :-( I think the best solution (if it works) is to put this transformation in rs6000's legitimize_address. Given a (plus (mult A B) C), force the mult into a pseudo (let's call it D) and then return (plus C D) with the operands swapped. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug tree-optimization/18687] [4.0/4.1/4.2 Regression] ~50% compile time regression
--- Comment #34 from rguenth at gcc dot gnu dot org 2006-09-03 13:22 --- FYI, the profile (-O2) looks like Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 2.04 0.62 0.62 5210670 0.00 0.00 htab_find_slot_with_hash 2.01 1.23 0.61 135824 0.00 0.00 find_reloads 1.78 1.77 0.54 1181450 0.00 0.00 constrain_operands 1.71 2.29 0.52 1667653 0.00 0.00 walk_tree 1.64 2.79 0.50 113076 0.00 0.00 record_reg_classes 1.18 3.15 0.36 1374013 0.00 0.00 for_each_rtx_1 1.15 3.50 0.35 2188275 0.00 0.00 iterative_hash_expr 1.02 3.81 0.31 13803214 0.00 0.00 bitmap_bit_p 0.99 4.11 0.30 146294 0.00 0.00 reload_cse_simplify_operands 0.92 4.39 0.28 8238693 0.00 0.00 bitmap_set_bit 0.89 4.66 0.27 13524760 0.00 0.00 is_gimple_min_invariant 0.85 4.92 0.26 1944894 0.00 0.00 extract_insn 0.76 5.15 0.23 3242786 0.00 0.00 note_stores 0.76 5.38 0.23 1848575 0.00 0.00 mark_set_1 0.76 5.61 0.23 1073359 0.00 0.00 fold_binary 0.69 5.82 0.21 3530376 0.00 0.00 ix86_decompose_address 0.66 6.02 0.20 2801807 0.00 0.00 is_gimple_reg 0.66 6.22 0.20 101 0.00 0.02 reload 0.62 6.41 0.19 6596295 0.00 0.00 find_reg_note 0.62 6.60 0.19 3748843 0.00 0.00 ggc_alloc_stat 0.62 6.79 0.19 1543768 0.00 0.00 force_fit_type 0.59 6.97 0.18 5160059 0.00 0.00 pool_alloc 0.59 7.15 0.18 937999 0.00 0.00 make_node_stat 0.59 7.33 0.18 1915 0.00 0.00 cleanup_cfg 0.56 7.50 0.17 2132681 0.00 0.00 mark_all_vars_used_1 0.56 7.67 0.17 1015399 0.00 0.00 get_expr_operands 0.56 7.84 0.17 263419 0.00 0.00 cse_insn 0.53 8.00 0.16 2162651 0.00 0.00 cselib_lookup 0.53 8.16 0.16 1176845 0.00 0.00 mark_used_regs 0.53 8.32 0.16 101 0.00 0.01 reload_as_needed 0.49 8.47 0.15 1748131 0.00 0.00 operand_equal_p 0.49 8.62 0.15 1160005 0.00 0.00 propagate_one_insn 0.49 8.77 0.15 1086424 0.00 0.00 et_splay 0.49 8.92 0.15 1030222 0.00 0.00 rtx_cost 0.49 9.07 0.15 523805 0.00 0.00 count_reg_usage 0.46 9.21 0.14 3222872 0.00 0.00 memory_operand 0.46 9.35 0.14 1651283 0.00 0.00 htab_find_with_hash 0.46 9.49 0.14 693604 0.00 0.00 rewrite_update_stmt 0.46 9.63 0.14 457856 0.00 0.00 mul_double we're hashing SCEV data a lot: 0.010.07 285600/2683522 set_instantiated_value [395] 0.010.09 398929/2683522 build_int_cst_wide [214] 0.020.20 864500/2683522 find_var_scev_info [184] [68] 2.30.060.63 2683522 htab_find_slot [68] 0.340.16 2683522/11019933 htab_find_slot_with_hash [53] 0.030.00 1150100/1603800 hash_scev_info [589] 0.060.03 125694/1181450 reload_cse_simplify_operands [94] 0.090.05 201473/1181450 find_matches [200] 0.320.16 698486/1181450 extract_constrain_insn_cached [67] [61] 2.70.540.28 1181450+14400 constrain_operands [61] 0.010.15 806498/873917 strict_memory_address_p [236] 0.050.00 272106/402044 operands_match_p [415] 0.050.04 100911/1588625 create_ssa_var_map [329] 0.070.06 144529/1588625 walk_tree_without_duplicates [268] 0.140.13 292781/1588625 count_uses_and_derefs [149] 0.210.20 450984/1588625 remove_unused_locals [111] [44] 3.90.520.68 1667653+3246362 walk_tree [44] 0.060.18 337362/337362 find_used_portions [189] 0.080.12 1659486/1659486 pointer_set_insert [209] 0.000.06 97327/97327 scan_for_refs [487] 0.050.00 1267779/1267779 count_ptr_derefs [525] 0.010.56 143418/143418 regclass [71] [80] 1.90.010.56 143418 scan_one_insn [80] 0.500.04 113076/113076 record_reg_classes [85] 0.010.01 100486/1944894 extract_insn [121] 0.000.07 209960/1775362 x86_extended_reg_mentioned_p [364] 0.020.26 747868/1775362 approx
[Bug tree-optimization/18687] [4.0/4.1/4.2 Regression] ~50% compile time regression
--- Comment #33 from steven at gcc dot gnu dot org 2006-09-03 11:41 --- FWIW, the oprofile for both test cases is basically flat, nothing stands out. We just do _so_ much more work (many more passes without removing anything) and that hurts apparently (not surprising of course). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug tree-optimization/18687] [4.0/4.1/4.2 Regression] ~50% compile time regression
--- Comment #32 from steven at gcc dot gnu dot org 2006-09-03 11:37 --- Just to be sure that between 7/24 and today we didn't speed up significantly: "real" times for hashes100.c (x86_64-linux, Intel Xeon 3.2 GHz, 1GB RAM): 3.4.6 4.2-svn20060903delta -O0 0m1.618s 0m1.634s +1% -O1 0m2.743s 0m5.175s +88% -O2 0m4.686s 0m7.719s +65% "real" times for infcodes100.c: 3.44.2-svn20060903delta -O0 0m3.040s 0m3.526s +16% -O1 0m4.989s 0m8.871s +77% -O2 0m8.375s 0m13.334s +59% Given these numbers, I would stick with gcc3 if I were a kernel developer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug tree-optimization/28900] [4.1/4.2 regression] ICE verify_stmts failed (invalid operand to unary operator)
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-09-03 11:32 --- I have a patch. The vectorizer oughts to use more of the infrastructure we have. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-30 15:23:02 |2006-09-03 11:32:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
[Bug tree-optimization/18687] [4.0/4.1/4.2 Regression] ~50% compile time regression
--- Comment #31 from steven at gcc dot gnu dot org 2006-09-03 11:05 --- "real" times for hashes100.c (x86_64-linux, Intel Xeon 3.2 GHz, 1GB RAM): 3.4.6 4.0.4 4.1.2 4.2-svn20060724 -O0 0m1.618s 0m1.762s 0m1.661s 0m1.645s -O1 0m2.743s 0m4.646s 0m4.984s 0m4.936s -O2 0m4.686s 0m6.814s 0m7.140s 0m7.603s "real" times for infcodes100.c: 3.4.6 4.0.4 4.1.2 4.2-svn20060724 -O0 0m3.040s 0m3.643s 0m3.555s 0m3.575s -O1 0m4.989s 0m7.694s 0m8.809s 0m8.943s -O2 0m8.375s 0m10.622s 0m12.136s 0m13.285s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug tree-optimization/28905] [4.2 regression] ICE in compare_name_with_value, at tree-vrp.c:3557
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-09-03 11:04 --- *** Bug 28941 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28905
[Bug c++/28941] ice in optimiser
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-03 11:04 --- *** This bug has been marked as a duplicate of 28905 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28941
[Bug tree-optimization/8361] [4.1/4.2 regression] C++ compile-time performance regression
--- Comment #70 from steven at gcc dot gnu dot org 2006-09-03 10:39 --- Based on my numbers of comment #69, I'm declaring this fixed once more. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
[Bug c++/28941] ice in optimiser
--- Comment #1 from dcb314 at hotmail dot com 2006-09-03 10:34 --- Created an attachment (id=12180) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12180&action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28941
[Bug c++/28941] New: ice in optimiser
I just tried to compile Suse Linux package djvulibre-3.5.17-4 with GNU C++ version 4.2 snapshot 20060902. The compiler said GMapAreas.cpp: In member function 'DJVU::GUTF8String DJVU::GMapArea::print()': GMapAreas.cpp:246: internal compiler error: in compare_name_with_value, at tree-vrp.c:3557 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 -O2 required. -- Summary: ice in optimiser Product: gcc Version: 4.2.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: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28941
[Bug tree-optimization/26969] [4.1 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #13 from victork at il dot ibm dot com 2006-09-03 07:51 --- this bug looks very similar to PR28839 which already have a fix in patch http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01171.html We need to check if above patch fixes PR26969 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug target/28137] "make check" gets 10 FAIL reports with gcc.dg/c99-typespec-1.c
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-03 07:30 --- (In reply to comment #5) > (In reply to comment #4) > > FAIL: gcc.dg/visibility-11.c scan-assembler [EMAIL PROTECTED] > > Yes this one is known. And that was fixed by: 2006-07-24 Uros Bizjak <[EMAIL PROTECTED]> * gcc.dg/visibility-11.c: Enlarge test array to 1024 bytes to avoid memcpy optimization. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28137
[Bug c++/28293] ICE on invalid typedef
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 07:27 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-03 07:27:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28293
[Bug middle-end/28205] Request an option to make -finstrument-functions not apply to inlined function calls
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 07:26 --- Confirmed, it is a little hard as -finstrument-functions now applied before inlining. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-03 07:26:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28205
[Bug libgcj/28009] libjava cannot be cross-built; X_CFLAGS includes /usr/include
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-03 07:23 --- This worked for me with using --with-sysroot=MYSYSROOT with a cross from i686-pc-linux-gnu to powerpc64-linux-gnu even with all the multilibs for ppc64 :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
[Bug other/28002] decNumber sources need GPL+exception for use in libgcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 07:20 --- Confirmed, any news on this? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-03 07:20:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
[Bug middle-end/27986] [4.0/4.1/4.2 Regression] jump to middle of loop on entry with using old version of an variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 07:18 --- Confirmed, Out of SSA should have created split the variable's range so that the conflicting parts are not changed inside the loop. before Out of SSA: # s_2 = PHI ; # d_1 = PHI ; :; D.1287_8 = MEM[base: d_1]; s_9 = s_2 + D.1287_8; d_10 = d_1 + 4B; if (s_9 < g_11) goto ; else goto ; # s_7 = PHI ; :; *v_3 = s_7; We should have changed s_7 into s.1 and added a move inside the loop before s_2 gets clobbered. I don't know the way of fixing out of SSA though. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2006-09-03 07:18:51 date|| Summary|jump to middle of loop on |[4.0/4.1/4.2 Regression] |entry with using old version|jump to middle of loop on |of an variable |entry with using old version ||of an variable Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
[Bug c++/28220] Segfault with pch and trying to do IMA with C++
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-03 07:05 --- bug.h just needs to contain: #pragma GCC pch_preprocess "/src/gcc/local/gcc/objdir/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch but that means we need to reduce that pch file also, I will try to do it maybe on Monday. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Summary|Segfault in top-of-tree |Segfault with pch and trying |development gcc |to do IMA with C++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28220
