--- 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
>
--- 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?
>
--- 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
--- 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 in
--- 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
--- 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
--- 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 #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 #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
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:
--- Comme
--- 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 @@ stru
--- 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 #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 #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 co
--- 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_dec
--- 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
--- 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 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"
> "ad
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
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",
--- 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
o
--- 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 u
--- 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|
--- 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 #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 #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.
--
htt
--- 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 #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 #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
#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;
--- 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"
--- 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
---
--- 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 #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 lindev
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
--- 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
--- 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
--- 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 #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: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 #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 fun
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")' ha
--- 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
--- 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
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: ‘deb
--- 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
---
--- 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
-
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 i
--
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
--- 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
--- 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/sh
--- 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 #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 b
--- 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
--- 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 #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 #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 #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 #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.
--- 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 #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 #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 #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
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
Ple
--- 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/bugz
--- 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 #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|UNCON
--- 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 #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 #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 #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];
--- 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
72 matches
Mail list logo
