=
>uname -a
Linux saturne 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 i686 GNU/Linux
=
>cat check-pshuf.cpp
ty
Compiling with "-Wall -O2" results in the correct execution of this code.
Compiling with "-Wall -O2 -finline-functions" with the code as attached, causes
the assertion to fail, which should not happen. However, if you uncomment
either of the std::cout lines in Decoder.cc or DecoderDerivs.cc and rec
--- Comment #1 from tim dot dawborn at gmail dot com 2009-11-08 09:45
---
Created an attachment (id=18992)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18992&action=view)
the code required to reproduce the bug
$ tar -zxf test.tgz
$ cd test
$ make clean all
$ ./main
main: Decoder
--- Comment #4 from brunorex at gmail dot com 2009-11-08 10:28 ---
Created an attachment (id=18993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18993&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
--- Comment #5 from brunorex at gmail dot com 2009-11-08 10:29 ---
Preprocessed source added.
Got this but should be normal:
gcc.exe: warning: -pipe ignored because -save-temps specified
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-08 11:31 ---
There's a typo here:
asm( "pshufd $0x55,%1,%&" : "=x"(A) : "g"(S) );
%& is not valid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-08 11:36 ---
You seem to run afoul generic floating point equality comparison issues.
best_score possibly modifies scores and calls back to best_equiv. Roudning
issues with the accumulation can lead to the failure.
So, we need
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-08 12:04 ---
I can't reproduce it on i?86-linux even before the PR41928 fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-11-08 12:10 ---
Subject: Bug 41928
Author: rguenth
Date: Sun Nov 8 12:10:32 2009
New Revision: 154008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154008
Log:
2009-11-08 Richard Guenther
PR rtl-optimization/4
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-11-08 12:10 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-08 13:45 ---
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00432.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
> gfortran -c -O1 bug.f90
bug.f90: In function Â__colvar_methods_MOD_qparm_colvarÂ:
bug.f90:13:0: internal compiler error: tree check: expected class ÂconstantÂ,
have Âbinary (rdiv_expr) in build_complex, at tree.c:1485
Please submit a full bug report,
with preprocessed source if appropriat
--- Comment #3 from tim dot dawborn at gmail dot com 2009-11-08 14:15
---
Thanks. Your comment sparked an idea. There is no bug in the logic of the
source code itself, nor should there be any floating point differences
anywhere. There should be no floating point differences as for every
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
Since at least revision 152615, I see the following failures on
i686-apple-darwin9 in 32 bit mode (see
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00699.html):
Running target unix
FAIL: g++.dg/debug/anonunion1.C -gdwarf-2 -g1 (internal compiler error)
FAIL: g++.dg/debug/anonunion1.C -gdwarf-2
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-08 14:55 ---
Works for me on i?86-linux, so which target and which revision?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
ran
--disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
--with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto
--enable-plugins
Thread model: posix
gcc version 4.5.0 20091108 (experimental) [trunk revision 154009] (
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-08 17:03 ---
This was more likely caused by HJL's stack alignment patches based on the
context of the ICE.
I had also saw this the last time I ran the testsuite on x86-darwin.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #8 from uros at gcc dot gnu dot org 2009-11-08 18:10 ---
Subject: Bug 41963
Author: uros
Date: Sun Nov 8 18:10:10 2009
New Revision: 154011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154011
Log:
Backport from mainline:
2009-11-06 Michael Matz
--- Comment #3 from kargl at gcc dot gnu dot org 2009-11-08 18:34 ---
Reduced test case.
SUBROUTINE qparm_colvar
COMPLEX ylm
ylm = 0
nbond = 0
ylm = ylm / nbond
END SUBROUTINE qparm_colvar
EMOVE:kargl[218] gfc4x -c -O -v jj.f90
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT
I noticed that when compiling with -march=geode the code is actually slower
than the one generated with generic options (i386 or i686).
This happens with any program, not just with dhrystone
# CFLAGS='-march=i386' ./dry.c
Dhrystones per Second: 643501
# CFLAGS='-march=i4
--- Comment #1 from rootkit85 at yahoo dot it 2009-11-08 18:51 ---
Created an attachment (id=18994)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18994&action=view)
the dhrystone benchmark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-08 18:55 ---
On which Geode is this on? Is this with the first generation Geode or the one
AMD made? Because if it is the latter, it is not really a Geode but a k6/k7
based processor.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-08 19:00 ---
Try -march=native instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
--- Comment #7 from paolo dot carlini at oracle dot com 2009-11-08 19:06
---
DR submitted, preview here, will be in R68:
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1245
Actually, the proposed resolution at the moment lacks the adjustments to the
hash and hash b
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41622
--- Comment #4 from rootkit85 at yahoo dot it 2009-11-08 19:52 ---
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 10
model name : Geode(TM) Integrated Processor by AMD PCS
stepping: 2
cpu MHz : 498.060
cac
Sent from my iPhone
On Nov 8, 2009, at 11:52 AM, "rootkit85 at yahoo dot it" > wrote:
--- Comment #4 from rootkit85 at yahoo dot it 2009-11-08 19:52
---
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 10
model name
--- Comment #5 from pinskia at gmail dot com 2009-11-08 19:57 ---
Subject: Re: Code optimized for AMD Geode is slower than generic
Sent from my iPhone
On Nov 8, 2009, at 11:52 AM, "rootkit85 at yahoo dot it"
wrote:
>
>
> --- Comment #4 from rootkit85 at yahoo dot it 2009-11-0
Provided a somewhat specific set of local variables, and as long as the code of
the function doesn't make any other function calls, gcc will decrease %rsp but
an incorrect and too small value. This leads to local variables being
corrupted when the execution is interrupted; this happens notably in
--- Comment #1 from cube at cubidou dot net 2009-11-08 20:27 ---
Created an attachment (id=18995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18995&action=view)
Test case
This very simple C file will expose the bug. In the assembler output, see how
only 152 is substracted to %r
The x86_64 abi includes a red zone. So I doubt this a bug in gcc
unless netbsd's abi does not match what gcc does.
Sent from my iPhone
On Nov 8, 2009, at 12:25 PM, "cube at cubidou dot net" > wrote:
Provided a somewhat specific set of local variables, and as long as
the code of
the functio
--- Comment #2 from pinskia at gmail dot com 2009-11-08 20:29 ---
Subject: Re: New: Incorrect stack setup on x86_64
The x86_64 abi includes a red zone. So I doubt this a bug in gcc
unless netbsd's abi does not match what gcc does.
Sent from my iPhone
On Nov 8, 2009, at 12:25 PM, "
--- Comment #3 from cube at cubidou dot net 2009-11-08 20:37 ---
Subject: Re: Incorrect stack setup on x86_64
On Sun, Nov 08, 2009 at 08:29:44PM -, pinskia at gmail dot com wrote:
>
>
> --- Comment #2 from pinskia at gmail dot com 2009-11-08 20:29 ---
> Subject: Re: Ne
--- Comment #4 from cube at cubidou dot net 2009-11-08 20:38 ---
Subject: Re: Incorrect stack setup on x86_64
On Sun, Nov 08, 2009 at 08:37:25PM -, cube at cubidou dot net wrote:
[...]
> 152 is too small even for the total size of the local variables (268 in
I meant 260 here.
--
--- Comment #5 from cube at cubidou dot net 2009-11-08 20:56 ---
Ok, I get it now. Not a gcc bug, we have to compile our kernel modules with
-fno-red-zone like the rest of the kernel.
Sorry for the noise.
--
cube at cubidou dot net changed:
What|Removed
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-08 21:13 ---
Subject: Bug 41985
Author: jakub
Date: Sun Nov 8 21:12:52 2009
New Revision: 154014
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154014
Log:
PR target/41985
* config/i386/i386.c (get_some_lo
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-08 21:15 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-08 22:27 ---
Subject: Bug 37290
Author: jason
Date: Sun Nov 8 22:27:39 2009
New Revision: 154018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154018
Log:
PR c++/37290
* pt.c (tsubst) [TYPEOF_TYPE]: Set c
--- Comment #6 from rootkit85 at yahoo dot it 2009-11-08 22:34 ---
(In reply to comment #5)
> Subject: Re: Code optimized for AMD Geode is slower than generic
>
>
>
> Sent from my iPhone
>
> On Nov 8, 2009, at 11:52 AM, "rootkit85 at yahoo dot it"
> > wrote:
>
> >
> >
> > ---
--- Comment #6 from jason at gcc dot gnu dot org 2009-11-08 23:06 ---
Actually, I'm not so sure:
template
struct A
{
typedef A arr[3];
};
template
void f(const typename A::arr) { }
template void f(const A::arr); // #1
template
struct B
{
void g(T);
};
template
void B::g(const
--- Comment #6 from jason at gcc dot gnu dot org 2009-11-08 23:11 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #6 from jason at gcc dot gnu dot org 2009-11-08 23:24 ---
14.7.4.1 [temp.point] says:
...the point of instantiation for such a specialization immediately follows the
namespace scope declaration or definition that refers to the specialization.
So, the point of instantiation
--- Comment #4 from kargl at gcc dot gnu dot org 2009-11-08 23:19 ---
(In reply to comment #2)
> I guess this could be related to the fact that MPC is not linked in. But here
> is the info
I think Joost is correct about the missing MPC library. I just
installed MPC-0.8 and rebuilt gcc.
--- Comment #16 from jason at gcc dot gnu dot org 2009-11-08 23:27 ---
It's not clear to me that there's anything to be fixed; the reduced testcase in
this PR works, and the testcase for 17910 seems to work the way the point of
instantiation rules say it ought to. And people can always
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-08 23:32 ---
Created an attachment (id=18996)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18996&action=view)
patch
Here's a patch that fixes the testcase and passes regression testing, but I
don't think it's the right way
--- Comment #8 from paolo dot carlini at oracle dot com 2009-11-08 23:41
---
Jason, the extra const in the library code is definitely unintended, I'm going
to remove it anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40315
The gcj compiler in 4.4.x and gcc trunk segfaults when compiling sample java
code like...
public class testme {
public static void main(String args[]){
System.out.println("Hello");
}
}
with "gcj --main=testme -O testme.java" with a failure of...
gcj: Internal error: Abort trap (prog
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-11-09
00:44 ---
A backtrace of the segfault under i686-apple-darwin10 for gcc trunk is...
gdb /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1
...
(gdb) r testme.java
-fbootclasspath=./:/sw/lib/gcc4.5/share/java/l
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-11-09
00:45 ---
(In reply to comment #1)
> A backtrace of the segfault under i686-apple-darwin10 for gcc trunk is...
>
This should have read...
A backtrace of the segfault under i686-apple-darwin9 for gcc trunk is...
--- Comment #6 from spop at gcc dot gnu dot org 2009-11-09 01:09 ---
This works in the graphite branch that will be merged soon into trunk.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
Hi
This piece of invalid code (the dereference shouldn't be there) triggers an
ICE. The crash happens on 4.3.2, 4.4.1 and 4.4.2. It happens with or without
optimizations.
static void MONITOR(void *ptr)
{
__asm__ volatile (" \n\
XORL%%ECX, %%ECX
Hi,
When I built gnustep-base, I got the following errors.
-
mframe.m:1250: warning: cast increases required alignment of target type
mframe.m: In function 'retframe_short':
mframe.m:863: internal compiler error: in create_pre_exit, at
mode-switching.c:399
Please submit a full bug report,
with
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-11-09 03:31 ---
-march=geode disables cmov because the real geode does not have cmov :).
This is why it is much slower.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2009-11-09 07:38 ---
(In reply to comment #5)
> bt with a memory object and a register index will _not_ truncate the argument:
Actually, we avoid bt with memory objects just because of this (handling of
memory op is not consistent with regist
57 matches
Mail list logo
