--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 06:03 ---
Confirmed, this works just fine with typedefs:
typedef void (*type1)(int n, int x[n]);
void foo(type1 p){}
So we have a problem by looking at some parts of the function declation:
SAVE_EXPR n;
--
pinskia at gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 06:08 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 06:10 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 06:13 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 06:28 ---
Reload 1: reload_in (V2SI) = (const_vector:V2SI [
(const_int -1
[0x])
(const_int -1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 06:30 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 06:30 ---
Confiremed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 06:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-03 06:37
---
(In reply to comment #9)
I just now tried that. Now I'm getting this error:
make: *** No rule to make target `bootstrap'. Stop.
That does not make sense.
Anyways try these instructions:
cd gcc-src # the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 06:37 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-03 06:41 ---
Fixed on the mainline:
t.cc: In function void bar() [with T = N::A]:
t.cc:9: instantiated from here
t.cc:4: error: argument dependent lookup finds N::foo
t.cc:7: error: in call to foo
Which means this is
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-03 06:41 ---
*** Bug 28348 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-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
--- 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 s_5(0), s_9(1);
# d_1 = PHI d_6(0), d_10(1);
--- 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
--- 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
--- 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
--- 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
--- 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]
--- 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.
--
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
--- 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=12180action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28941
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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).
--
--- 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
--- 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
--- 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
--- 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
--- 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
--
--- 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
--
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
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
--- 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
--- 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
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 #8216;int main()#8217;:
assert_testcase.cpp:16:
--- 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=12181action=view)
Testcase code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
--- 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=12182action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
On Sun, 2006-09-03 at 19:35 +, lindevel at gmx dot net wrote:
assert_testcase.cpp: In function #8216;int main()#8217;:
assert_testcase.cpp:16: error: #8216;debug(((const char*)Some
string))#8217; has type #8216;void#8217; and is not a
throw-expression
That says to me that the expression
--- 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
--- 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. */
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
#ifdef __i386__
#include cstdio
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;
--- 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
--- 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.
--- 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
--- 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.
--
--- 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
--- 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
--- 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
--- 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
--- 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
following testcase should work but it fails at least on ia32.
#include cstdio
struct base
{
virtual ~base() { }
virtual void foo() = 0;
int val;
};
struct derived : public base
{
void foo()
{
std::printf( foo(): this - %p, val = %d\n,
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
--- 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,
--- 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
--- 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
--- 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,
--- 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
--- 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
--- 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
--- 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 @@
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 #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
--- 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
--- 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
--- 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
78 matches
Mail list logo
