--- Comment #11 from pault at gcc dot gnu dot org 2007-05-24 08:10 ---
Just to let you all know; I have had a patch ready for this and PR30875 for
somewhile. This was awaiting the commit of Brook's simplify_transfer patch and
all the machinery in target-memory.c. Well, during the wait
--- Comment #6 from ubizjak at gmail dot com 2007-05-24 08:28 ---
This is just a "problem" in the testsuite. gcc figures out that blendpd with
0x03 (and blendps with 0x0f) immediate operand can be substituted with simple
move. H.J. has been informed about this and will update the tests.
gcc -march=pentium4 -O2 cast.c
cast.c: In function âmainâ:
cast.c:88: error: unrecognizable insn:
(insn 11 10 12 3 cast.c:52 (set (subreg:TI (reg:TD 63) 0)
(subreg:TI (const_double:TD 0 [0x0] 2.0 [N/A]) 0)) -1 (nil)
(nil))
cast.c:88: internal compiler error: in extract_insn, at recog.c
--- Comment #1 from ubizjak at gmail dot com 2007-05-24 09:05 ---
Rediced testcase (the constant is not important):
_Decimal128 test (void)
{
return 1234123412341234.123412341234dl;
}
gcc -O2 -msse
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32065
--- Comment #153 from rguenther at suse dot de 2007-05-24 09:03 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Thu, 23 May 2007, gdr at cs dot tamu dot edu wrote:
> --- Comment #151 from gdr at cs dot tamu dot edu 200
--- Comment #154 from rguenther at suse dot de 2007-05-24 10:07 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote:
> Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
>
--- Comment #155 from rguenther at suse dot de 2007-05-24 10:11 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Thu, 24 May 2007, rguenther at suse dot de wrote:
> So I did some benchmarking with my two proposed patches (wh
--- Comment #156 from gdr at cs dot tamu dot edu 2007-05-24 10:29 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"rguenther at suse dot de" <[EMAIL PROTECTED]> writes:
[...]
| > I brought in the union example to point of a fu
--- Comment #157 from rguenther at suse dot de 2007-05-24 10:33 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Thu, 24 May 2007, gdr at cs dot tamu dot edu wrote:
>
>
> --- Comment #156 from gdr at cs dot tamu dot ed
--- Comment #158 from gdr at cs dot tamu dot edu 2007-05-24 10:47 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"rguenther at suse dot de" <[EMAIL PROTECTED]> writes:
[...]
| > Now, if I understand your argument below correc
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-24 10:54 ---
is this fixed on pointer_plus branch? Confirmed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-24 10:57
---
Subject: Bug 32038
Author: fxcoudert
Date: Thu May 24 09:56:50 2007
New Revision: 125019
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125019
Log:
PR fortran/32038
* gfortran.dg/pr25603.f
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-24 10:57
---
Fixed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-24 11:09 ---
Actually this is just a tree-combining issue. CCP already transforms this to
c_1 = &b.t[0];
D.2000_3 = i_2(D) * 4;
D.2001_4 = (int *) D.2000_3;
D.2002_5 = D.2001_4 + &b.t[0];
*D.2002_5 = 1;
not combining
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-24 11:11 ---
Confirmed. Of course it needs to read
char *c = b->t;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from dannysmith at gcc dot gnu dot org 2007-05-24 11:12
---
Subject: Bug 27067
Author: dannysmith
Date: Thu May 24 10:11:49 2007
New Revision: 125020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125020
Log:
ChangeLog
PR target/27067
* doc/tm.t
--- Comment #17 from dannysmith at users dot sourceforge dot net
2007-05-24 11:18 ---
Fixed on trunk
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-24 11:22 ---
I have a patch for this one.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following is adapted from the example from the C++ standard, clause 14.6/4
(actually it's the updated version from DR345):
1 struct A {
2 struct X { };
3 static int X;
4 } ;
5 template void f(T t) {
6 typename T::X x; // inva
--- Comment #11 from bero at arklinux dot org 2007-05-24 11:53 ---
ping...
> This is known and will not be fixed until 4.2.
Now that 4.2 is released and it still doesn't work, can we get this working in
4.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
It gives an unexpected result while doing xor operation on a templated class.
For sample, here is my simple code:
--
#include
using namespace std;
template
inline void XOR-Swap(T &a, T &b)
{
if (a != b)
a ^= b ^= a ^= b;
};
i
The codes below basically builds a binary tree. It runs well on Intel
compiler. However, when I use gcc 4.2.0, the assignment to b[i].right
causes segmentation fault. Tracing with valgrind reveals that the
particular memory address was deleted during push_back().
If I change the assignments to
--- Comment #1 from pluto at agmk dot net 2007-05-24 12:31 ---
(In reply to comment #0)
> Any comment?
this is an example of undefined behaviour.
http://blogs.msdn.com/rick_schaut/archive/2004/03/06/85357.aspx
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32067
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-24 12:47 ---
*** This bug has been marked as a duplicate of 32018 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-24 12:47 ---
*** Bug 32006 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
-bash-3.2$ /usr/local/gcc/bin/gcc -O0 -fsplit-wide-types /tmp/segfault.c -S -o
/dev/null
/tmp/segfault.c: In function 'segfault':
/tmp/segfault.c:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html
--- Comment #1 from rask at sygehus dot dk 2007-05-24 13:28 ---
Created an attachment (id=13608)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13608&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32069
Configured as
../configure --prefix=/mnt/home3/piotrw/tower/tools/gcc-4.1.2
--enable-threads=posix --with-dwarf2 --enable-languages=c,c++
When trying to build 4.1.2 using GCC3.4.4 on a PA-RISC-based
HPUX machine, the following error is reported:
make[3]: Entering directory
`/export/home3/piotrw/
--- Comment #13 from malitzke at metronets dot com 2007-05-24 14:08 ---
Mr Guenther!
Thank you (herzlichen Dank) for the information about the hopefully disabling
flag. If that information would have been posted after my initial intervention
we could have saved a lot of bandwidth and st
--- Comment #12 from patchapp at dberlin dot org 2007-05-24 13:57 ---
Subject: Bug number PR29786
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/2007-05/msg01609.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from pcarlini at suse dot de 2007-05-24 14:01 ---
(In reply to comment #0)
> If I change the assignments to
>
> int x = build_recursive(n-1);
> int y = build_recursive(n-1);
> b[i].left = x;
> b[i].right = y;
>
> there is
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-24 14:39
---
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
The following C++ code should not compile:
template
class C
{
template
class C2 { };
};
template<> template
class C::C2 { };
template<> template
class C::C2 { };
The first specialization has too many parameters.
the second specialization has the wrong type of parameters.
The C++ standard cl
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-05-24 15:02 ---
Subject: Bug 32018
Author: rakdver
Date: Thu May 24 14:02:12 2007
New Revision: 125024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125024
Log:
PR middle-end/32018
* tree-ssa-threadupdate.c
--- Comment #7 from hjl at gcc dot gnu dot org 2007-05-24 15:12 ---
Subject: Bug 32062
Author: hjl
Date: Thu May 24 14:12:18 2007
New Revision: 125025
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125025
Log:
2007-05-24 H.J. Lu <[EMAIL PROTECTED]>
PR testsuite/32062
--- Comment #8 from hjl at lucon dot org 2007-05-24 15:13 ---
All SSE4.1 testcases should fail now if assembler dosn't support SSE4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
--- Comment #2 from andrew dot stubbs at st dot com 2007-05-24 15:27
---
You can create an array of functions. Also prohibited by clause 14.8.2/2.
template int f(T[5]);
typedef void (fn)();
int K = f(0);
At least it doesn't seem to accept reference types ...
--
andrew dot stubbs
--- Comment #14 from dominiq at lps dot ens dot fr 2007-05-24 15:31 ---
I have run what I can of the testsuite (gcc, g++, gfortran, and objc) without
regression. I have also run my version of the polyhedron tests and got:
with Makefile.*'s from revision 124627
1891.060u 84.040s 33:15.8
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-24 16:21 ---
http://gcc.gnu.org/bugs.html#nonbugs_c
*** This bug has been marked as a duplicate of 11751 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #75 from pinskia at gcc dot gnu dot org 2007-05-24 16:21
---
*** Bug 32067 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 16:33 ---
I think the proper fix here is to disable this warning in tools.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-24 16:37 ---
(In reply to comment #14)
>
> The flag just disables an optimisation. If you want to disable optimisations
> just use -O0. On the other hand, shouldn't -ffreestanding prevent udivdi3 ?
> What about -fno-builtin-udivd
--- Comment #14 from manu at gcc dot gnu dot org 2007-05-24 16:27 ---
(In reply to comment #13)
>
> To sum up; as a user, and, in the UNIX spirit (I started with the 7th
> edition),
> I just want freedom in choosing the facilities and features gcc has to offer.
> I
> hope that this or
--- Comment #2 from markus dot duft at salomon dot at 2007-05-24 17:18
---
Have you disabled DEP? A description of how to do this can be found here:
www.interopsystems.com
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31109
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 17:18 ---
I think gjdoc only recently got support for generics and annotations.
So an older gjdoc is expected to fail. I haven't been keeping track
of gjdoc version numbers but I expect if you install a newer version
this will
The bug is present in the 4.2.0 release and still in the 20070523 snapshot.
It was not present in 4.2-20070405-1 (from Debian experimental).
The error occured in a program using stxxl (http://stxxl.sourceforge.net) with
mcstl (http://algo2.iti.uni-karlsruhe.de/singler/mcstl/). Since mcstl requires
--- Comment #1 from gcc at abeckmann dot de 2007-05-24 17:26 ---
Created an attachment (id=13609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13609&action=view)
preprocessed source code of the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32072
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 17:31 ---
Could you get a stack trace at the point of the ICE?
That might help.
If that doesn't help, though, all that remains is debugging jc1
to see what goes wrong.
If you have the time another thing to try is building a la
--- Comment #2 from deknuydt at esat dot kuleuven dot be 2007-05-24 17:51
---
(In reply to comment #1)
>
> If you have the time another thing to try is building a later version,
> for instance svn trunk. Maybe you've stumbled across a bug that
> got fixed later on.
I tried 4.2.0 which
--- Comment #12 from tromey at gcc dot gnu dot org 2007-05-24 17:59 ---
Do you have a copyright assignment?
If so I will review the proposed patch.
I think the bigger problem is that the Qt peers are not really maintained.
ISTR that they still have some pretty serious bugs, though that
--- Comment #3 from tromey at gcc dot gnu dot org 2007-05-24 18:02 ---
Unless you need 4.1 and plan to work on this bug, I would like to close it.
What do you think?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31853
--- Comment #2 from pcarlini at suse dot de 2007-05-24 18:36 ---
This is an mcstl issue, of which we are not responsible: if look inside
PR32072.ii you will discover that somehow, in basic_ios.h, the fill method has
been replaced by an __mcstl_hidden_fill and the fill method is not avail
Loops with a bounded, small number of iterations unroll too much. They should
be peeled away instead. For example, if I compile the following function with
``-O3 -funroll-loops'':
void short_loop(int* dest, int* src, int count) {
// same happens for assert(count <= 4) and if(count > 4) exit(-1)
--- Comment #3 from gcc at abeckmann dot de 2007-05-24 19:04 ---
But why does g++ behave differently if called with different optimization
levels?
I was looking for a mcstl bug first, but since g++ accepted this code with -O2
I went for g++.
On the other hand, if this is actually a bug i
--- Comment #4 from pcarlini at suse dot de 2007-05-24 19:07 ---
Please, stop fiddling with Bugzilla. I pointed you to the real reason of the
bug, and you should simply report it to mcstl. And of course, GCC is allowed to
behave differently at different optimization levels, because at lo
It would be nice if the optimizer took advantage of assertions. I realize that
assertions may not be enabled for production code, but even when disabled they
are still explicit statements of the programmer's assumptions; the compiler
should be able to exploit those assumptions if it yields better c
--- Comment #5 from pcarlini at suse dot de 2007-05-24 19:43 ---
Something we *can* do is more strictly inhibiting implicit instantiation of
__ostream_insert (already ok in mainline). But really, mcstl should never touch
the basic_ios::fill function, has nothing to do with std::fill.
-
--- Comment #2 from rob1weld at aol dot com 2007-05-24 19:48 ---
The configure script ought to check for gjdoc version - I _do_ have the newest
version from using "apt-get update" apt-get upgrade" - how are people supposed
to use the "--with-gjdoc" if it is not better documaented?
The g
--- Comment #2 from fang at csl dot cornell dot edu 2007-05-24 19:55
---
Suggestion: determine some lower bound of the size (or exact) N prior to a
sequence of push_back()s, and call vector::reserve(N) in advance. Then as long
as the capacity isn't exceeded, you avoid any reallocation.
--- Comment #9 from rob1weld at aol dot com 2007-05-24 20:03 ---
Thank you for looking into this, everyone. I do appreciate it working
correctly.
Here is the extreme steps I took to fix "my" problem. It is not reasonable that
the average person would be assumed to know this (something i
--- Comment #7 from rob1weld at aol dot com 2007-05-24 20:05 ---
Thanks, works OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
--- Comment #1 from fang at csl dot cornell dot edu 2007-05-24 20:07
---
It would be nice to unify (run-time) assertions with compile-time directives as
a fine-grain mechanism for telling the compiler what it can or cannot assume.
'restrict' is one example where the non-aliasing constr
--- Comment #15 from sje at cup dot hp dot com 2007-05-24 20:50 ---
*** Bug 32070 has been marked as a duplicate of this bug. ***
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #1 from sje at cup dot hp dot com 2007-05-24 20:50 ---
HPPA HP-UX platforms do not support the dwarf debugging format.
*** This bug has been marked as a duplicate of 9468 ***
--
sje at cup dot hp dot com changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-24 22:48 ---
VRP information is not preserved over optimization passes, so loop unrolling
does not know about it. But VRP recognizes that count is <= 4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-24 22:54 ---
__builtin_expect should not be overloaded, but __builtin_assert/assume/whatever
could be invented for this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
While looking into some failures on the pointer plus branch after fixing up
forwprop, I noticed that we would get a failure in the vectorizer testsuite and
the reason is because we no longer could determine dependence for the two data
accesses.
Here is the testcase which is a modified version of v
--- Comment #3 from fang at csl dot cornell dot edu 2007-05-24 22:57
---
Subject: Re: Optimizer does not exploit assertions
> --- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-24 22:54
> ---
> __builtin_expect should not be overloaded, but
> __builtin_assert/assum
--- Comment #2 from ian at gcc dot gnu dot org 2007-05-24 23:12 ---
Subject: Bug 32069
Author: ian
Date: Thu May 24 22:12:31 2007
New Revision: 125043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125043
Log:
PR rtl-optimization/32069
* regclass.c (regclass): Do
--- Comment #3 from ian at airs dot com 2007-05-24 23:14 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RE
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-25 02:05 ---
Ok, I have a patch for this issue, I am going to test it with -ftree-vectorize
-msse2 while bootstrapping too to make sure that we don't have really any
regression due to data reference going wrong (the previous patc
--- Comment #1 from dj at redhat dot com 2007-05-25 03:02 ---
Indeed the SI is suspicious, since the m32c family doesn't have those types of
pointers (it has HI or PSI pointers, but not SI). I've never tried to build
FORTRAN for the m32c family though, so if there's a FORTRAN developer
--- Comment #27 from maddox at google dot com 2007-05-25 04:57 ---
(In reply to comment #20)
Ian proposed handling the simple case in which the two constructors ("clones")
are identical by emitting the code only once, but labelling it with the symbols
for both constructors. This scheme
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-25 05:38 ---
There seems to be a consensus on this - confirmed.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
When looking at fixing one bug and using compare_tests, I noticed that in some
cases the test names can be the same even though it is testing two different
dump files.
gcc.dg/tree-ssa/pr17141-1.c is one example.
It does:
/* { dg-final { scan-tree-dump "locp.*->i =" "forwprop1" { xfail *-*-* } } } *
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-25 07:17 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-25 07:34 ---
Subject: Bug 32047
Author: pault
Date: Fri May 25 06:34:10 2007
New Revision: 125057
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125057
Log:
2007-05-25 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-25 07:35 ---
Resolved on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-25 07:35 ---
You know the testresults are not looked at by almost nobody (I am one of the
few person who looks at them).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
79 matches
Mail list logo
